CSS reading-flow property

[dizhang168]

こんにちは TAG-さん!

I'm requesting a TAG review of the CSS reading-flow property.

The CSS Working Group has resolved to add the new reading-flow property (w3c/csswg-drafts#8589, spec) to enable focus navigation in visual order for layout items that might not be displayed in source order (such as grid, flex and masonry items). Chromium is implementing the new property and opened a whatwg/html#10407 on the needed HTML spec change.

• Explainer: HTML Spec proposal
• Hosted examples
• Specification URL
• Tests
• User research: Multiple blog posts link 1, link 2, link 3
• Security and Privacy self-review²: Mostly not applicable because this is adding a new CSS property.
• GitHub repo: https://github.com/w3c/csswg-drafts
• Primary contacts (and their relationship to the specification):
  • Di Zhang (@dizhang168), Google, implementer in Chrome
  • Rachel Andrew (@rachelandrew), Google, spec editor
  • Tab Atkins (@tabatkins), Google, spec editor
  • Mason Freed (@mfreed7), Google
  • Ian Kilpatrick (@bfgeek), Google
• Organization(s)/project(s) driving the specification: Google and the CSS WG
• Key pieces of multi-implementer support:
  • Chromium comments: supportive
  • Mozilla comments: CSS reading-flow mozilla/standards-positions#1056
  • WebKit comments: CSS reading-flow WebKit/standards-positions#378
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • Chromestatus
  • chromium bug
  • csswg-drafts resolved issue
• This feature should be inclusive of other API/features:
  • Accessibility
  • OpenUI focusgroup
  • Masonry

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: hoping to ship this property soon.
• The group where the work on this specification is currently being done: CSS Working Group, WHATWG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): CSS Working Group, WHATWG
• Major unresolved issues with or opposition to this specification: [css-display-4] Define how reading-flow interacts with focusable display: contents elements. w3c/csswg-drafts#9230
• This work is being funded by: Google

[matatk]

Hi @dizhang168, thanks for your review request. I have an accessibility question: the examples that I've seen in the explainers concentrate on showing how the (keyboard) focus navigation order, and visual rendering order, would be kept in synch when using reading-flow (which will be great, especially for masonry layout).

The examples I've seen all use interactive elements (specifically <buttons>) to demonstrate this. I just want to confirm: would this re-ordering apply to all content (i.e. not just interactive elements), though? (I am thinking of the case where, for example, a screen reader user would be navigating via their virtual cursor, following the order of content in the accessibility tree.)

From the explainers, and CSS spec, I imagine the intention is for the ordering to affect all content (not just interactive elements) - effectively the accessibility tree will come from the visual order, rather than source order.

Am I understanding this correctly?

[tabatkins]

Correct, focusable elements are just the easiest way to demonstrate this without requiring people to run a11y software themselves.

[dizhang168]

Yes, this feature is for both focus navigation and the accessibility tree (the order in which AX nodes are added to the tree).

[matatk]

Thank you @tabatkins, @dizhang168 for confirming (also, that is a neat idea and inclusive approach, re the examples). One further thing that came up in APA WG's discussion (HT @AutoSponge) is: we were wondering if there may be a need (practical/implementation or otherwise) for signals from the UA to the AT when a big reflow occurs (especially thinking of the Masonry case).

We are also following up with our AT vendor contacts, to see how much (if any) caching of the accessibility tree they do. If they don't need to do any, it may not be an issue, but if they do, such signals may be needed to ensure the reflowed layout is reflected.

If you have any thoughts on this, do let us (or APA WG may be a good avenue—you could use the "a11y-tracker" label) know. If we find out anything interesting, we'll feed it back to you.

[dizhang168]

I don't think implementation wise it will be an issue. When the grid/flex/masonry layout gets created, the rendering-defined sibling reading flow gets stored. So, for the AT, the additional step is just looping these reading flow items (no need to calculate on the fly). If we do need to send a signal, it should be trivial to add.