[csswg-drafts] [css-display-4] reading-flow should affect entire focus order, not only tab order (#11909)

extra808 has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-display-4] reading-flow should affect entire focus order, not only tab order ==
[reading-flow](https://www.w3.org/TR/css-display-4/#reading-flow) changes the reading order of a flex or grid area so that it better corresponds to the visual order, so it makes sense to the reader. When the area contains not only static content but also elements in the focus order, it's necessary for this order to match the new reading order. "Focus order" and "tab order" are often used synonymously, as using Tab and Shift-Tab are the main keyboard interactions for moving through a page's focus order, but arrow keys are also used to move focus in HTML, between `<input type="radio">` buttons and between options in a `<select>`.

Most screen reader users have some vision and sometimes use it so keeping the visual, reading, and focus orders in sync helps avoid confusion. Also for keyboard users without a screen reader, having tab navigation altered by `reading-flow` but not arrow key navigation could be confusing; think of a toolbar, that uses tab navigation between button groups and arrow key navigation within them, but the order of buttons can be explicitly customized by the user or updated to put frequently used buttons first.

### Radio buttons
Within a radio button group, the checked radio is first focused (or the first radio in the reading order, if none are checked) when pressing Tab, and they're navigated between using right/down to focus the next radio, left/up the previous radio, and wrapping around when an end of the radiogroup is reached.

Currently in Google Chrome Canary, `reading-flow` changes the reading order to match an altered visual order but not the arrow key navigation. When navigating element-by-element using a screen reader's keystrokes, it should follow the new reading order. However, it's common for AT users to use Tab and arrow keys, as other keyboard users do, to navigate and operate form elements. Changing the order for one navigation mode but not another is arguably worse than not using `reading-flow` at all.

* [radio buttons with reading-flow](https://codepen.io/ccwilcox/pen/ZYEJwda?editors=1100).
* [CSS grid - dense with radios with reading-flow](https://codepen.io/ccwilcox/pen/OPJWNNg?editors=1100).
* [Tabs pattern using radio buttons with reading-flow](https://codepen.io/ccwilcox/pen/EaxgLdB).

### Customizable selects
The options of a `<select>` element have not been styleable but [work is being done](https://github.com/whatwg/html/issues/9799) to change that. Currently in Google Chrome Canary, the visual order of options may be changed and `reading-flow` will change the reading order but navigation with arrow keys remains in the DOM order. Note that in addition to up/down arrow keys, **Home** and **End** keys may be used to focus the first and last options in a `<select>`, respectively.

[Customizable `<select>` with reading-flow](https://codepen.io/ccwilcox/pen/bNGrddb?editors=1100).

### Non-native keyboard navigation
JavaScript is often used to implement a "roving tabindex" in ARIA patterns like [Tabs](https://www.deque.com/axe-con/sessions/a-solution-for-the-visual-and-source-order-disconnect/) and [Grid](https://www.w3.org/WAI/ARIA/apg/patterns/grid/), making a set of controls a single "tab stop" and responding to arrow keys to move on one axis or both axes (mentioned in [#9922](https://github.com/w3c/csswg-drafts/issues/9922#issuecomment-1963085593)). I can't think of how `reading-flow` could help, I think for those use cases it remains necessary for the DOM order and visual orders to correspond and make sense together.

### Future possibilities
If future additions to HTML bring additional keyboard interactions ([focusgroup](https://open-ui.org/components/focusgroup.explainer/) attribute, styleable elements for other [ARIA patterns](https://www.w3.org/WAI/ARIA/apg/patterns/), styleable versions of other user agent inputs such as a date picker), their participation in the focus order should likewise be changed with the reading order by `reading-flow`.

(@rachelandrew, this is a follow-up to my questions at your [axe-con 2025 presentation](https://www.deque.com/axe-con/sessions/a-solution-for-the-visual-and-source-order-disconnect/).) 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11909 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 11 March 2025 15:54:18 UTC