[css-display-4] reading-flow should affect entire focus order, not only tab order

[extra808]

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.
• CSS grid - dense with radios with reading-flow.
• Tabs pattern using radio buttons with reading-flow.

Customizable selects

The options of a <select> element have not been styleable but work is being done 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.

Non-native keyboard navigation

JavaScript is often used to implement a "roving tabindex" in ARIA patterns like Tabs and 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). 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 attribute, styleable elements for other ARIA 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.)