tabindex vs reading-flow property

[tabatkins]

What is the issue with the HTML Standard?

Currently, the reading-flow PR has the behavior that 'reading-flow' makes the element a scope container for tabindex, and within that scope, tabindex ordering is consulted first, with visual-order giving tiebreaking between identical values. (I think that's a correct summary of the current behavior?)

During the CSS/WHATWG joint session at TPAC, we concluded that it would be better to make tabindex more subordinate to 'reading-flow'.

The exact proposed behavior is:

1. On the "reading flow items", tabindex is ignored for ordering purposes (it still makes the items focusable as normal, etc). 'reading-flow' is explicitly taking over the ordering of these elements.
2. On the descendants of the "reading flow items", tabindex's ordering behavior is scoped to that reading flow item subtree. (Aka the reading flow items are scope containers for tabindex, like the spec currently defines for the "reading flow container".)

The participants in the discussion believed this has a more predictable and desirable behavior for authors. Ignoring tabindex's ordering effects on the reading order items themselves seems useful; it allows authors to use tabindex to define one particular ordering, in particular a non-visual one (or one for legacy UAs), and then let 'reading-flow' override that in other cases.

Similarly, having each item be a scope for their descendant tabindexes seemed to better match the mental model we were working with, where 'reading-flow' effectively rearranges the reading order items.