Eslint-plugin-jsx-a11y: please delete

[ghost]

x

[evcohen]

This should be:

<form onSubmit={whateverYourSubmitFnIs}>
   ....
   <button type="submit" />
</form>

Then in your onSubmit fn, you do e.preventDefault()

I think this will pick up on the enter button for submit

[ljharb]

@jaepage a user hitting return doesn't necessarily trigger any submit button - in fact, it's generally not reliable and a bad idea to ever have more than one submit button, because it's generally not reliable to determine which one was clicked.

[ljharb]

(O.o if you're subscribed, then pinging you won't give you a different notification, and if you're not, then this will resubscribe you - it's exceedingly common github etiquette to at-mention people when you want to be sure your comment is seen as a direct reply)

It may be valid HTML, but all browsers don't implement that spec consistently. The proper solution would be to have one submit button, and a checkbox for the flag, and then to use JS to map the checkbox so it looks like a button, checks the box on click, and then auto-submits the form.

That said, if you wanted to listen to shift-return, you'd certainly need a key listener on the <form>, since as you pointed out, it'd be impractical to put the listener on every element.

I think adding an option to the rule for an explicit list of exceptions (ie, form, MyComponent, etc) makes perfect sense here.

[evcohen]

@ljharb (sorry for the double notification 😝)...I think I'm against this config option, but can be convinced. I think users should manually disable the rule via comments in these cases. This indicates in the source that this _may_ be bad design for a11y reasons. By obscuring the ignored components into an .eslintrc file, users may be unknowingly implementing inaccessible content.

[ljharb]

That's also a good point. Since in the case of disable comments, it'd only require it in the one place, that also seems reasonable.

[ghost]

x

[ljharb]

That it is done, does not mean it is correct, and the way Github does it is not accessible nor gracefully degradable for the very reasons I've indicated.

[jessebeach]

form, table and dialog fall into this weird category where they often host interaction handling.

The reason that <form> is not interactive is that it descends from structure ontologically: https://www.w3.org/TR/wai-aria-1.1/#structure

I'm not opposed to adding further configuration to no-noninteractive-element-interactions that would whitelist specific handlers on a per-element basis.

https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/src/index.js#L75

Maybe something like:

'jsx-a11y/no-noninteractive-element-interactions': [
  'error',
  {
    handlers: [
      'onClick',
      'onMouseDown',
      'onMouseUp',
      'onKeyPress',
      'onKeyDown',
      'onKeyUp',
    ],
    allowedOnElements: {
        form: ['onKeyPress']
    }
  },
],

But I agree as well that a disabling comment is also a valid solution here.

[jessebeach]

Addressed in #281

[jessebeach]

Addressed in #281 .