[css-nav-1] Accessible keyboard control

[nattarnoff]

The specification states that spatial navigation can be used via keyboard control

Using a UA-defined mechanism (typically arrow keys, possibly in combination with modifier keys like Shift or Control)

I'm pushing to narrow this to specifically be the arrow keys and no modifiers. People with physical disabilities may be limited in being able to press key combinations. I'm fully supportive of browsers having a way for people to redefine the keys to something they prefer (w a s d for example), but these may required adding a modifier to not interfere with input inside the spatial navigation container.

[tabatkins]

We, in general, can't put any actual requirement on browser interfaces. That sentence is descriptive of the situation, not adding a requirement.

[nattarnoff]

I would then recommend modifying the language in the specification to either point out this potential issue or recommend limiting the input types due to this issue.

[jihyerish]

I'm fully supportive of browsers having a way for people to redefine the keys to something they prefer (w a s d for example), but these may required adding a modifier to not interfere with input inside the spatial navigation container.

window.navigate() in the spec provides to alter the keys for moving the focus.

When you use this, you can control the focus with w a s d keys. You can check how it works here: https://wicg.github.io/spatial-navigation/demo/sample/api_navigate.html

I would then recommend modifying the language in the specification to either point out this potential issue or recommend limiting the input types due to this issue.

Thank you for suggesting more detailed language in the specification. I think putting this modification in the [window.navigate()] seems nice.

[fuzzbomb]

I'm pushing to narrow this to specifically be the arrow keys and no modifiers.

There's a huge problem with this. Spatial navigation is intended to move focus between focusable elements. However many focusable elements already have arrow key behaviours which affect the focused element itself. For example:

• The up/down arrow keys change the value of a <select>, or a radio button group.
• Arrow keys work inside text inputs, to aid editing.
• ARIA tablists are also expected to have arrow key behaviours to change tab (rather like radio buttons). This is intended to follow the behaviour of tablists on native desktop applications.
• The arrow keys are used to shift the the content of any scroll container which has focus (or contains a focused element) as long as the focused element doesn't claim the arrow keys.
  • Note this includes the top level page container; the down key is commonly employed by keyboard-only users when they just want to read the page rather than operate any controls which are in the page.

These behaviours are long established, for decades now.

The upshot is that spatial navigation typically can't use the arrow keys without modifiers, because then there would be no way to change the value of a radio button group, say. Granted, there may be some devices (KaiOS?) which have a different mechanism for changing the value of inputs; so it's best for the spec to let user-agents decide.

People with physical disabilities may be limited in being able to press key combinations.

For which there is the sticky keys feature, available in all the major operating system (Windows, macOS, Gnome, KDE plasma, XFCE, Solaris, Android, iOS). It's been around since the mid-late 1980s and is a popular feature among motor-impaired users.

Another common approach is to use a programmable "macro" keypad, and map some of those keys to send shift+arrow by pressing just one key.

or recommend limiting the input types due to this issue.

What are we saying here... spatial navigation can be used to reach links and buttons, but not text inputs, radio buttons, or ARIA tablists? That would pretty much defeat the object of spatial navigation.

[anawhj]

I'm pushing to narrow this to specifically be the arrow keys and no modifiers.

The a11y is one of the important motivations on spatial navigation, so people with physical disabilities can utilize it without any modifier keys for granted. As @tabatkins mentioned above, it depends on product requirements so seems out of scope in the spec.

In an LG TV browser case, the spatial navigation currently works only with enabling a11y mode which doesn't require any modifier key in remote control. Most of the implementations will consider what you pointed out above, while W3C has always reviewed all specifications from a11y point of view.