[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...