W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2021

Re: [csswg-drafts] [css-nav-1] Accessible keyboard control (#5683)

From: Andrew Macpherson via GitHub <sysbot+gh@w3.org>
Date: Thu, 26 Aug 2021 22:36:25 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-906788808-1630017384-sysbot+gh@w3.org>
> 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](https://en.wikipedia.org/wiki/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.

GitHub Notification of comment by fuzzbomb
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5683#issuecomment-906788808 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 26 August 2021 22:36:27 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:42 UTC