w3c
[css-display-4] reading-flow/reading-order vs text selection
Does reading-flow/reading-order affect text selection and caret navigation?
Test selection seems rather tricky but I can see why it would make sense.
Caret navigation seems like a clear yes, though I would have to check how tab-index plays into that.
Wrote this code snippet to test it out. Both the text selection and the caret navigation follow the DOM order on all browsers. AFAIK, neither CSS order nor tabindex affect the text/caret selection.
It would be really tricky to implement this behavior based on reading-flow. It wouldn't be a case of re-ordering the sibling children of a specific container anymore. And how are we meant to interpret the different reading-flow keyword values?
Moved from related FSO issue:
If reading flow affects focus but not selection and caret navigation, there may be a mismatch between types of mixed navigation modes uses by assistive tech users...
- many screen reader users use a combination of navigation mechanisms which don't seem to be accounted for in the focus scope owner proposal
- linear AT (e.g. next/prev)
- non-linear AT (e.g. next heading)
- linear arrow (next/prev char or word)
- non-liner arrow (e.g. move down a line or page), and
- tab-based navigation (e.g. next focusable)
- it's not clear to me if focus scope owner would result in a more or less predictable order in a timer-stepped switch interface... For example, some Switch Control users have their step speed set as fast as 50ms (1/20 of a second), so predictability is obviously critical.
The CSS Working Group just discussed [css-display-4] reading-flow/reading-order vs text selection.
The full IRC log of that discussion
<ydaniv> fantasai: a11y tree, some questions about reading flow with text selections and navigations<ydaniv> ... we don't have an answer for this, but some concerns
<masonf> q+
<ydaniv> Rossen3: PaulG5 on the call, can we have some help from a11y folks?
<ydaniv> PaulG5: yeah, can do that
<Rossen3> ack masonf
<bkardell> q+ to ask if there are any actual user studies?
<masonf> https://github.com/w3c/selection-api/issues/336
<ydaniv> masonf: wanted to say, couple of related issues, about text selection, flat tree vs layout tree
<ydaniv> ... quick conclusion that for selection it's pretty tough
<ydaniv> ... requires selection API to support multiple ranges
<ydaniv> ... so carefully saying we have issues here
<ydaniv> Rossen3: can I also ask you to cross link issues?
<Rossen3> ack bkardell
<Zakim> bkardell, you wanted to ask if there are any actual user studies?
<ydaniv> masonf: one of the comments has a link to the issue
<dbaron> (Gecko has historically supported multiple-range selections although I'm not sure if it still does.)
<ydaniv> bkardell: I worry that users will find this intuitive, would rather we have a study to get this right
<ydaniv> PaulG5: there are some screen reader users in APA that can help
<ydaniv> ... we just had a meeting this morning, will send another call out to the group
<ydaniv> Rossen3: thank you, anything else?
Also see https://github.com/w3c/selection-api/issues/336
Note that for the selection API, "fixing" this might not be straightforward. Selecting a chunk of text that doesn't appear in DOM order means that the browser must support multi-range selection. The Selection API issue above is about whether the selection API should operate on the flat tree or the composed tree. This issue is, I think, about perhaps changing that to use the layout tree (since that's the visible thing users see and select). That's even more difficult, for the same reasons, plus the added fact that the layout tree isn't 1:1 with the DOM tree. I'm concerned that this is a fairly large can of worms, but I'd love to be proven wrong.
Arrow key navigation (for e.g. radio buttons and customizable-select) and caret navigation are likely somewhat easier to fix. I'd agree that it would be good for all of these behaviors (as much as possible) to follow reading-flow/reading-order.
I agree with Mason's analysis for Chromium (why is there no +1 reaction?).