Post by @urlyman@mastodon.social

TIL that for an HTML source order that provides a natural read (good), but reflows elements for design reasons with CSS grid (or flexbox)…

VoiceOver reads them out in the *designed* order. Which is pissing me off.

I also learn that there’s a CSS fix for this kind of thing with the `reading-order` property but:

a) my initial reading is the fix’s emphasis is to make things follow the visual order (which is the opposite of my dilemma)
b) it has low support anyway

https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/reading-flow

#a11y

7 Replies

0 Boosts

Jonathan Schofield

@urlyman@mastodon.social 3 hours ago

…Any advice #a11y folks can offer for my dilemma? (see above)

My use case:

diligent HTML source order of:

- eventTitle
- weekday DD month YYYY, startTime to endTime

but laid out via grid as

- weekday DD month YYYY, startTime to endTime
- eventTitle

…gets read out by VoiceOver as the latter 🥹

Jonathan Schofield

@urlyman@mastodon.social 3 hours ago

…Hmm, this BBC accessibility guide highlights a screwy state of affairs https://www.bbc.co.uk/accessibility/forproducts/guides/mobile/content-order/

iOS: “By default, VoiceOver will read page content based on the screen layout” (true of Mac OS as well).

Android: “By default, TalkBack will read page content based on code order”.

IMO, Android is clearly doing the *right thing* here: code should reflect semantic flow; visual design can be divergent from that so should not be the #a11y cart leading the horse.

What do accessibility folks think?

Screenshot of the linked BBC page from which the quoted text is drawn. The quoted segments are highlighted.

Curtis Wilcox

@cwilcox808@c.im 2 hours ago

@urlyman
That quote is only about iOS native apps, not web content. I've never seen it before but I haven't done work on native app accessibility.

VoiceOver (all platforms) will read web content in the order in which it appears in the accessibility tree, which will largely match the source code order.

Jonathan Schofield

@urlyman@mastodon.social 1 hour ago

@cwilcox808 Thanks. I realise the focus of that article is native apps, but I quoted it because it describes what I experience in VoiceOver today on Mac OS for a web design prototype I’ve coded up. Which is to say…

it most definitely does *not* read in the order followed by the accessibility tree (AT).

However, I’ve just discovered that this issue seems to be limited to Firefox (and forks):

- Chrome: AT order
- Safari: AT
- Firefox: visual order
- Waterfox: visual (my default browser)

1 more replies

Jonathan Schofield

@urlyman@mastodon.social 3 hours ago

…I presume this stupid mismatch of OS vendor strategies is what `reading-order` seeks to normalise.

I need to read up more on it.

- - -

I’m a visual designer who codes. I try to do the right thing, but I’m embarrassed to admit that I’m late to this awareness of the impact of grid/flexbox on *read order*.

I’ve long known that *tab order* is a concern, but this is a new level of messiness :/

Curtis Wilcox

@cwilcox808@c.im 2 hours ago

@urlyman
The `reading-flow` CSS property is meant to change the reading order (and focus order) to match the visual layout instead of source code order for Flexbox and Grid layouts that make them differ. But it's only supported in Chromium browsers. (`reading-order` is for adding tweaks to the `reading-flow` order).

The campaign to add `reading-flow` to the standard was specifically to improve the experience with those layouts and to provide a solution before another new way to make the visual and source orders deviate shipped, that is, `grid-lanes` (aka masonry layout). Unfortunately, Safari has shipped `grid-lanes` support but not `reading-flow` support.

Discussion

Discussion