Aliases for certain type of key press events

[danielimmke]

Describe the problem

I get this a11y message all the time when I put a on:click on an element that isn't normally clickable. It says I also need to have a on:keydown etc... so if someone is navigating with their keyboard, it will still work.

The problem is the code for this is extremely verbose:

on:click={clickHandler} on:keydown={(e:KeyboardEvent) => { if(e.key === 'Enter') return clickHandler(e) }}

Yes, it is possible to write an abstraction that would cut down on it a bit, but then everybody's creating different solutions to the same issue.

Describe the proposed solution

Navigation by keyboard is usually only a few keys: Tab, Shift + Tab, Enter, Arrow Keys.

The same way Svelte has a lot of things like conditional attributes to tighten up the render markup, I think it would be cool if there were aliases that could be used. For example: on:click={clickHandler} on:enter={clickHandler}

I feel like this is the actual intent 99% of the time, and if this alias existed and satisfied the a11y warning I bet people would use it.

Alternatives considered

Trying to combine the event handlers like on:click:enter - but I think that would be messy looking, and they are still two different events (the functions would receive a MouseEvent for click and a KeyboardEvent for enter, so should be handled separately.

Importance

would make my life easier

Additional Information

I know I can create my own use actions. I will try to do <svelte:window use:enter /> and see if that lets me implement this on all elements. I hope I don't have to do use:enter on:enter={} for each time.

[Conduitry]

This has come up before in #4427 and in some other issues. I'm not that much more enthusiastic about the idea than I was then. I'm definitely against a syntax like on:enter={}, because enter isn't the name of the event.

[danielimmke]

I see where you're coming from. Would it be better to use more verbose names like on:returnkey or is it just the fact that they wouldn't be the names of real DOM events at all?

The only other approach I can think of would be scoping. Maybe like on:keydown:enter would be a good compromise? It's just a modification of a real event that would still save space and remove boilerplate.

[brunnerh]

Just use the correct elements, see:

• Improve click event handler accessibility warning #8001

[7nik]

What about letting people create custom event modifiers?

function enter (fn: (ev: KeyboardEvent) => void) {
    return function (this: HTMLElement, ev: KeyboardEvent) {
        if (ev.key === "Enter") {
             fn.call(this, ev);
        }
    }
}

on:keypress|enter={handler}

[danielimmke]

Just use the correct elements, see:

• Improve click event handler accessibility warning #8001

This really isn't always practical, especially when you have more complex UI elements. Wrapping everything in an anchor tag or button brings a lot of additional potential issues. SvelteKit does its own magic with anchors, and a lot of times you aren't trying to navigate to a different route but affect a state change on the current route. The existence of aria attributes in the HTML spec acknowledges that you can't always use the correct elements, so I think it's worth discussing further here too.

[brunnerh]

I would agree that there are edge cases where you may need to use other elements, but this does not justify adding obscure magic to Svelte that will lead to problems elsewhere. Often what people try to do as a workaround via events does not even work; the warning you get from Svelte also confirms that, as it fails to mention that enabling focus is also required to make keyboard events trigger.

a lot of times you aren't trying to navigate to a different route but affect a state change on the current route

That is why most of the time you should just use <button>, anchors are for navigation after all. Would love to hear about those other issues because I fail to see them when using the correct elements for the job.