Re: [csswg-drafts] [css-display-4] reading-flow/reading-order vs text selection (#12014)

On one hand, I tend to agree that:

1. From a user perspective, focus order is very closely related to "logical reading order". If you tab through a document and you get a b c, it's perhaps weird if moving with caret browsing/selection gets you c b a.
2. If we're going to say "this is the logical reading order" and we're codifying that at a web platform level (not just an accessibility specific level), it's fair to argue that it really should be consistent.

On the other hand:

1. With specific regard to accessibility APIs, this difference already applies to aria-owns. To be fair, ARIA has an explicit history of not messing with anything other than the accessibility tree, for better or worse.
2. As I understand it (and I confess I don't understand it well), caret navigation for complex cases in all browsers has been quirky at the least in all kinds of ways for a very long time. This isn't an excuse to make it worse, but it's a consideration when getting into cases outside of editable content.
3. Screen readers use the accessibility tree and reading-flow reorders that. My understanding is that other kinds of AT being discussed here, including switch control, rely either on the accessibility tree or tab focus (also reordered). So I don't anticipate this being a problem when browsing or navigating content, whether linear or non-linear. That said, @cookiecrook, are there cases you're thinking of here which would somehow be impacted by browser caret/selection navigation that I'm missing; i.e. where an AT relies on that instead of the accessibility tree/tab focus?

The one really messy case I can foresee here is if content inside an editable area gets reordered using reading-flow. In editable content, screen reader users at least rely heavily on the browser's keyboard support for caret navigation and text selection, and those commands won't currently follow reading-flow. That means that the order used by the screen reader to report text (the accessibility tree) will be mismatched with the order used for caret navigation and text selection keyboard commands (DOM), which seems like it could be quite nasty indeed. FWIW, both Gecko and Chromium completely disallow aria-owns in contentEditable for this reason among others.

-- 
GitHub Notification of comment by jcsteh
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12014#issuecomment-3931297415 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 20 February 2026 02:49:37 UTC