[click-events-have-key-events] but why?

[rchl]

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?

[vhoyer]

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:

• https://codepen.io/vhoyer/pen/JjKpPMR

[rchl]

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).

[vhoyer]

yeah, but does the validation triggers for you on buttons and anchors?

[rchl]

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. :)

[vhoyer]

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

[vhoyer]

OOh, I see, sorry for the confusion :sweat_smile: