click-events-have-key-events applies to native buttons and links

[TheAlexLichter]

Native elements like <button> or <a> (also counting <nuxt-link> / <router-link> into it) don't need additional handlers beside a @click or @click.native listener.

Adding another handler for keydown events will actually lead to bugs and double execution of the function.

Maybe we should add a whitelist to that rule

[maranran]

<router-link> actually render to <a> by default , so you don't need use <a> outside。maybe you can use <!-- eslint-disable-line --> in complex situation @manniL

[TheAlexLichter]

@maranran Sorry, I don't understand 🤔

[rafaelmaiach]

@maranran I'm having this problem even with button elements:

 <button class="button" @click="save">
     {{ buttonText }}
 </button>

Eslint throws: Visible, non-interactive elements with click handlers must have at least one keyboard listener.

I'm using the extends recommended

[i-hardy]

I'm having this issue too with button elements. @maranran it looks like there's a commented-out line with a todo in https://github.com/maranran/eslint-plugin-vue-a11y/blob/master/lib/rules/click-events-have-key-events.js regarding interactive elements, which I assume pertains to buttons, links etc- I'd be happy to have a go at getting this to work and making a PR.

[juliamoses]

Can we get some progress on this. Adding the recommended setting causes the event to be triggered twice. As an example

<button @click="toggle">
    <i class="fa fa-angle-down accordion-icon" :class="{ rotate: show }"></i>
</button>

The above code is fully accessible using keyboard and mouse navigation but will fail the linting.

On making the recommended change to <button @click="toggle" @keyPress="toggle"> will trigger the function call twice when using a keyboard.

[matthewdouglas]

@juliamoses This seems to work for the button example when fixing the todo that @i-hardy mentioned.

I've done this in my fork here matthewdouglas@f116519

For the anchor tags, they need to have a href attribute to meet this rule.
<a href="" @click.prevent="something">click me</a>

[juliandreas]

Would be cool if this could get fixed.

[marcus-herrmann]

@maranran What was the reasoning behind commenting out https://github.com/maranran/eslint-plugin-vue-a11y/blob/master/lib/rules/click-events-have-key-events.js#L31? Is @matthewdouglas' fork the solution, or has it side effects? Can contributors help in any way regarding this? I'm eager to support, because this is a critical false negative that could keep developers from using eslint-plugin-vue-a11y altogether.

[matthewdouglas]

@marcus-herrmann I'm not aware of any side effects.

This plugin is based on the react version, which has had the isInteractiveElement check since the rule was first added: infofarmer/eslint-plugin-jsx-a11y@ec4f193#diff-aeea5a0f9f93bda6f7d13946feb947bf

That said, I'm not entirely sure if the underlying implementation for isInteractiveElement is the same.

[marcus-herrmann]

Either way, I forked, removed the comment, and adapted it a little, like this: https://github.com/vue-accessibility/eslint-plugin-vue-a11y/blob/master/lib/rules/click-events-have-key-events.js#L31

In a project using this fork the rule works as intended. Failing at <div @click="" />, but accepting <button @click="" />, same with <a>.

[grace-snow]

Can this fix be added to this solution via PR instead of a fork?

It makes any tools relying on es-lint-plugin-vue-a11y unusable (e.g. the VS Code extension) in a team setting as it forcing devs to have the knowledge to ignore this one warning