A11y on:click event must be accompanied by an on:keydown — add assignment like on:click=on:keydown={}

[Ohyenno]

Describe the problem

To work with a11y, in addition to clicking, you need to register the processing of keyboard pressing. In this case, if the call function is the same, there is duplication and littering of the code.

I would like to be able to list several types of call in a row.

Describe the proposed solution

These could be solutions:

on:click=on:keydown={}

or
on:click|:keydown={}

or custom method
on:ckd={}

Alternatives considered

Alternatively, make the click method automatically duplicate keydown if no special definition is specified

Importance

would make my life easier

[Prinzhorn]

make the click method automatically duplicate keydown if no special definition is specified

Oh no 😨

You forgot the most important bit of the message which is non-interactive elements. In general the solution is to use interactive elements such as <button> that already have that behavior (a focused button will "click" when pressing "enter").

In other cases where you know you don't need it you can still apply <!-- svelte-ignore a11y-click-events-have-key-events -->. E.g. I do that when I use event bubbling. E.g. the wrapper has on:click and there is no a11y issue, because I just want the bubbled clicks of the interactive elements inside.

[Conduitry]

The things you should be putting on:click on should be interactive elements - and, as noted above, this warning is only present when you attach a click handler to a non-interactive element without a keyboard handler. If you know what you're doing, you can use a comment to disable the warning.

If you do want a keyboard handler on the element, you're likely going to want different handlers for clicking and keydown (because otherwise your code would be triggered for every key, including tab, arrow keys, etc.). If you find yourself in this situation frequently, I would encourage you to write a simple action that encapsulates this logic and attaches the appropriate mouse and keyboard actions. I don't think this is something the framework ought to handle.

And lastly, no, we definitely don't want to be attaching implicit keydown handlers when you attach a click handler.

[EskelCz]

@Conduitry @Rich-Harris With all the focus on accessibility, it would be great to have at least one article on best practices from Svelte standpoint. All the warnings are a great stick, but there's no carrot, no easy path to follow.

It's frustrating, since dynamic links can be done in dozen ways and Svelte seem to be trying to push you to use one specific, but doesn't tell you exactly which one.

span on:click in a problem, span with tabindex is problem, <a href='javascript:' is a problem, <a href='#' is a problem, <a without href is a problem... etc etc. So a developer who would like to do the right thing but doesn't have much time to invest into it just throws hands into the air and disables A11y altogether.

For example this: <a on:click={ () => history.back() }>arrow_back_ios</a> (using material icon font)
Triggers:

1. "A11y: visible, non-interactive elements with an on:click event must be accompanied by an on:keydown, on:keyup, or on:keypress event."
2. "A11y: element should have an href attribute"

It's a navigation thing, so semantically it should use "A" tag. But href doesn't make sense. Buttons are also styled in a different way, so using a button would require additional css reset just for that specific button.

[unikitty37]

Agreed. When I search the Svelte documentation for keyup, this is all I find:

That tells me I should use keyup or keydown rather than keypress — but it does not tell me how to use them. Surely that is the whole point of documentation?

There's nothing in the event handling section of the tutorial, either — it's all about clicks.

If the Svelte documentation doesn't tell us how to write a keyup handler, Svelte should not be complaining that we haven't done so!