[click-events-have-key-events] but why?
Closed this issue · 6 comments
I'm wondering about the reasoning for the click-events-have-key-events rule. I would think that having a @click handler is enough in many cases since it will also handle keyboard space & enter when used on interactive (focusable) elements. So why would it be necessary to also add explicit key handlers?
What happens is that, when you are using an element that is supposed (according to the HTML language) to accept interaction, e.g: button, a, the browser makes the @click work with space & enter, but on all other elements (divs, ems, spans, imgs), when you use a @click listener, it will only listen for click events.
You can read more on this subject on:
- https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role
- https://benfrain.com/converting-divs-into-accessible-pseudo-buttons/
You can also test this behavior by yourself here:
I understand that but as you said, those types of elements already handle being triggered by the keyboard so the error is a false positive in those cases.
It would likely make sense to exclude those kinds of elements and potentially allow configuring custom ones (although that might be premature).
yeah, but does the validation triggers for you on buttons and anchors?
Ops. Sorry, it works as expected.
I've reported this based on running the older brother of this plugin (https://github.com/maranran/eslint-plugin-vue-a11y) which actually has this issue. 🤦 Sorry. :)
if you check the lint code to see the library is testing for interactive elements: https://github.com/vue-a11y/eslint-plugin-vuejs-accessibility/blob/master/src/rules/click-events-have-key-events.js#L44
OOh, I see, sorry for the confusion 😅