Element focuses with any key
SuselMan opened this issue · 11 comments
Steps to reproduce:
- Click any selectable element.
- Press any key except 'Tab'
Actual result:
The element from the first step has afocus-visibleclass.
Expected:
The element has notfocus-visible.
Thank you =)
I think the behavior you're describing might be working as intended. If the user switches to keyboard modality we want to show them where their focus is.
Can you provide an example from your application where this behavior is unexpected or undesirable?
Yeah, I have an item list, where each item can be chosen by the shortcut, so if I click to one of them and then use the shortcut for selecting another I don't expect that tab navigation will be enabled.
I think if you select something with a keyboard, no matter via shortcut or not, the item should match :focus-visible.
Actually not, cos tab navigation just sets an element as active, and dispatch click with 'enter' key, unlike shortcut which begins click behaviour immediately; Also shortcuts can do something not related to navigation, and in these cases focus-visible is unexpected;
@SuselMan which keys are you using for the shortcut? We are updating :focus-visible to ignore shortcuts that start with a modifier key.
These shortcuts are without a modifier like 'A, F, S' or arrows, which often are used for tools as an example. Actually, it also can be a combination is setted by a user. Is there any reason to handle other keys besides Tab and Shift+ Tab?
The web content accessibility guidelines (WCAG) 2.1 were recently updated to recommend not using single character key shortcuts, or if you do use them, to make it so the user can change them to use a modifier key. This is because many screen readers already use single character keys for navigation. NVDA, for instance, uses the "F" key to move to the next form.
The arrow keys are also commonly used for navigation in accessible components. For instance, a tablist where the user can press the left/right arrows to focus the next tab.
Because there might be various ways someone could use a piece of assistive technology to move focus around the page, the heuristic we use is pretty simple. If the action that preceded focus was from a keyboard press, then we assume the user is navigating via a keyboard or some other piece of assistive technology that simulates a keyboard, and we match :focus-visible on the focused element.
We do not match :focus-visible if focus was preceded by a modifier key shortcut as that is the current recommended way of doing shortcuts according to WCAG.
For what it's worth, this also matches the behavior in Chrome.
Here's an example. Mouse-click the button. Then press any key on your keyboard. You'll see that the focus indicator shows up because the browser has decided that the user is now navigating via the keyboard.
@SuselMan I'm curious to understand why this behaviour is unwelcome, as well. Our thinking has been that if you are interacting via the keyboard, you want to know what you're interacting with, regardless of how you moved focus. If this thinking doesn't agree with yours, I'm interested to understand why and what we might have missed.
@alice, @robdodson I have researched the question, and actually seems like you are right. This behaviour is usual. There are some troubles for me with legacy one-key shortcuts, especially, when Enter is one of them in special app states. Thank you, and sorry for your time.