Re: [csswg-drafts] [css-flexbox][css-grid] Providing authors with a method of opting into following the visual order, rather than logical order (#7387)

I am so sorry to have spammed this with so very many words. I also have ignored all other comments because this is long enough.

I appreciate that the opening lays out the current situation, but there are a couple assumptions within worth reconsidering:

> […] With care from the author in creating a good document, this in general works well for screen reader users. […]

Some examples might be handy here. Moving an image visually before a heading in a card layout is good example (so the image retains its position, and meaning, following the heading in the DOM).

> […] For example, by being able to show something visually near the top of the page but, because it would be repetitive for a screen reader user, physically locate it in elsewhere in the document. […]

This _may_ be true in some contexts for blind screen reader users. But since [¼ to ⅓ of screen readers are _not_ blind](https://adrianroselli.com/2017/02/not-all-screen-reader-users-are-blind.html) this tends to be a problem. I am wary of the broad strokes here because I see devs making assumptions about "repetitiveness" and visual placement often.

> ## Problem
> ### Visual/tab order disconnect for keyboard users
> […] Authors also want to be able to reorder content at different breakpoints, to provide the best presentation of the layout for different amounts of screen real estate. In this case again, it is likely that by starting with a sensible document source, a screen reader user will not be affected.

A _blind_ screen reader user may not be affected. A blind screen reader user who contacts support, or has a sighted person guide them in any way, may discover that directions like "the box after the heading" are meaningless when the DOM order does not match the visual layout. A low-vision screen reader user may also struggle when zooming causes breakpoints to visually reflow the visual order distinctly from the DOM order. The example, however, is a fantastic visual demo.

> ### Impact on screen reader users if the author assumes the visual order is the logical order
>  […] the screen reader user is going to hear things in a different order than the author intended. […]

No tweaking here; I am using this opportunity to let readers know that some screen reader users do not hear the output, but instead experience it on a Braille display. It should not affect this conversation much, but it is worthyknowing.

> - [Twitter thread](https://twitter.com/jlengstorf/status/1531506923811483648) (the demo uses order to re-order things by interest, it was pointed out this may have accessibility issues)

The "zero client-side JS" example is a bit of a red herring. Truly accessible interfaces would leverage script to re-order the content as appropriate. Most CSS-only UI efforts have questionable accessibility since things like state, properties, values all have to be managed and live outside the scope of CSS.

> - [Using the Grid Shepherd Technique to Order Data with CSS](https://css-tricks.com/using-the-grid-shepherd-technique-to-order-data-with-css/)

This is another case where a CSS-only solution is only performing a visual change. This is the job for a DOM re-order via script. Not only that, developers (should) have [known for years that CSS flex/grid-only solutions break semantics](https://adrianroselli.com/2018/02/tables-css-display-properties-and-aria.html#Videos) (not linking much-maligned original tweet), even though browsers fixed those gaps. That 2019 post should not have survived testing in real use.

> ## Proposal
> Provide a method in CSS for authors to opt into following the visual order when in a flex or grid context.

Essentially mimic how [Firefox used to behave](https://adrianroselli.com/2015/09/source-order-matters.html#Update01) (2015), before it was changed (January 2016 / Firefox 44). At least, that is how I am reading this. These old bugs may be useful to peruse to understand why the change (or not?):

- [#1107734 CSS flexbox order is not mapped into accessible tree](https://bugzilla.mozilla.org/show_bug.cgi?id=1107734) (2014)
- [#812687 Don't reorder frame tree for flex items (because "order" shouldn't affect tab-index / nav-index)](https://bugzilla.mozilla.org/show_bug.cgi?id=812687) (2012)

> For example:
> […] ` focus-order: visual;` […]

This is where I have my issue — the concern is about _reading_ order, which begets focus order based on position in the DOM. The property name is disconnected from the intent or, if the intent is only to apply to focusable elements, will create greater problems as those will break from surrounding context.

- If this is meant to affect visual order, then how will it resolve conflicts with the existing `order` property?
- Does this only apply in a flex/grid context, and if so, what about absolute positioning and floats?

There is a genuine risk of a reading order, focus order, _and_ DOM order disconnect. Incidentally, those are two separate WCAG Success Criteria to consider:
- [1.3.2: Meaningful Sequence](https://www.w3.org/WAI/WCAG21/Understanding/meaningful-sequence.html) (Level A)
- [2.4.3: Focus Order](https://www.w3.org/WAI/WCAG21/Understanding/focus-order.html) (Level A)

> An opt in would enable use cases such as [this thread](https://twitter.com/jlengstorf/status/1531506923811483648).

I maintain that thread is a red herring. The wrong tool is being used for the job. Script should have been employed to re-order the DOM.

>  It would also mean visual design tools that allow people to create layout by drag and drop could add the opt-in as soon as the user started to create a layout that had the potential of reordering.

I don't understand. A design tool like Figma or like WordPress's block editor? The former should not render production code and so this proposal would be moot in that context. The latter suggests a visual designer is already working with a developer to enable some form of reflow. This may also be my lack of imagination.

> We could also consider making the default ordering visual in cases such as grid masonry layout, or auto-flow: dense where reordering is almost inevitable.

If this means what I think it means, I refer readers to the Firefox issues I linked.

> ## Alternate approaches and related work
> ### An HTML attribute

For all the reasons cited, and years of `tabindex` misuse, I agree this is not a good approach.

> ### CSS Spatial Navigation
> The [Spatial Navigation](https://drafts.csswg.org/css-nav-1/) spec proposes a method of navigating a 2d space.

Spatial navigation is meant only for interactive controls. Which, again, causes me concern since disconnecting focus order and reading order brings a bunch of unnecessary risk. Which is also why I am confused about this proposal overall since it seems to alternately equate the two and ignore one or the other.

Anyway, if readers want to try spatial navigation, I have [instructions how you can do it _today_](https://adrianroselli.com/2022/06/keyboard-only-scrolling-areas.html#Update01) as part of a larger post about keyboard navigation in scrolling content areas (which maybe should be a concern within this proposal as well).

> ### Open UI: focusgroup
> The [focusgroup](https://open-ui.org/components/focusgroup.explainer) primitive aims to facilitate focus navigation using arrow keys.

My comments about spatial navigation generally apply here, minus being able to play around with it.

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


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

Received on Tuesday, 21 June 2022 00:36:40 UTC