[focusgroup] Should focusgroup direction follow the DOM order or the visual order?

[gfellerph]

In the current version of the focusgroup explainer, the direction can be restricted to inline and block directions. However, there are many ways to alter the visual order of elements that can be combined in many different ways. A particularly cursed example would be this focusgroup maze on codepen.

In this example, the tab key moves focus through the buttons in DOM order. Because of the many directional changes applied in CSS, tabbing through the buttons seems to move the focus in random order (positions 4, 3, 5, 2, 1).

While this is the expected behavior of the tab key, it might be problematic for the arrow keys when pressing the right arrow key moves the focus visually to the left.

Which order should focusgroup follow when identifying the next candidate to focus?

1. Should focusgroup always respect the visual order for selecting the next element to focus? (What would this mean for assistive technology?)
2. Should focusgroup only support certain properties, e.g. writing-mode but not others like transform. If yes, what properties should be supported and which should not be supported?
3. Should focusgroup move focus in DOM order (respecting limitations on up/down and left/right arrow keys based on inline or block direction)?

There are most likely other things to consider and more possible answers to the question.

[lukewarlow]

https://drafts.csswg.org/css-display-4/#reading-order-items - this feels relevant here

[travisleithead]

Interesting. From @lukewarlow's link, this line in the "Design Considerations" section seemed particularly relevant:

Linear navigation, focus sequencing order, and screen-reader order should always match, because there are users who use them together.

Would that imply that arrow key navigation would also jump around (like TAB) in the above cursed example because it would also be following DOM order (despite the weird visual appearance)? If a screen reader's perception of the content would follow the same DOM order logic, that would make the most sense to me from an accessibility standpoint...

[gfellerph]

That makes a lot of sense (and will make the implementation easier, I guess).

[dizhang168]

I am currently prototyping the changes for CSS reading-flow in chromium, in FocusController. Because the focusgroup prototype is currently under FocusgroupController, it is currently opted out of the feature. Note that this feature is specifically for elements with display: grid and display: flex, which is a different concept from the Grid for this feature (which is more for tables, from what I have seen).

Now, if a focusgroup container is also a reading flow container and we want it to follow the visual order, we would need to update the advance logic in FocusgroupController. I think that should be doable. If interested, I would encourage you to take a look at the HTML standard proposal (whatwg/html#10407) and other active conversations.