[Proposal] Mechanism to mark up “alternative” read order

brennanyoung · 2023-01-11

“Content order” is an important design characteristic, especially for accessibility (“a11y”).

It is intimately connected with ‘good semantics’. WCAG 2.1 specifies several success criteria which pertain to this characteristic:

Users of Assisitive Technologies (ATs) such as screen readers rely on authors arranging their content in such a way that the most meaningful “next” item appears subsequently in the DOM. Similarly, the “tab sequence” is most reliable when it follows the order of operable elements in the DOM.

In most cases, this works very well. It is a modest constraint which is relatively easy to follow.

However, there are classes of content which are not well-served by this approach. To generalize, this content is characterised by the potential for (or expectation of) multiple viable pathways, to the extent that the information, structure, and relationships conveyed through presentation are neither fully programmatically determined, nor readily reduced to flat text.

Some Concrete Use Cases

Mathematical expressions and chemical formulae - where the most appropriate ‘reading’ might traverse the expression in multiple directions.
Flow Charts - where content is related by connecting lines (which may themselves have labels) that often express branches, jumps and loops.
Data Views - where the ‘story’ is expressed by how data points relate to the value of other data points (or other arbitrary limits and thresholds), irrespective of the sequence in which they are plotted (i.e. irrespective of DOM order).
Filters and sorting mechanisms which permit subsets of large amounts of data to be approached according to distinct (but arbitrary) criteria.
CSS flex-direction, grid, floats and absolute position - where content may be deliberately presented visually in a sequence that differs from DOM order.

Ideal and Necessary Features

The mechanism should be exposed to user agents’ accessibility APIs in a consistent and predictable way.
The mechanism should complement/extend rather than replace existing accessibility tree implementations.
It should be possible to ‘browse’ the alternative reading pathways, without switching to a fully operational interaction mode. This is especially relevant for assistive technologies that make a distinction between “browse mode” (aka. “document mode”) and “forms mode” (aka. “applications mode”).
Looped content pathways should be supported. (A simple tree structure is not enough).
Going ‘backwards’ should be supported, perhaps requiring some kind of history stack logic, that remembers which path was taken, even if multiple alternative paths might otherwise have been taken.
Connecting lines/paths should permit (but not require) naming (i.e. “accessible names” for assistive technology).
Nodes should permit rich text structures such as lists, headings etc. and not limited to flat/plain text. We have flowchart boxes that contain headings, bullet lists, hints in subscript, emphatic text and so on.
Branching structures (such as choice boxes in a flowchart) should be semantically distinct enough that AT users are appropriately cued about navigating the change in flow.

Prior Art

Anchors / hyperlinks. The primary abstraction of HTML is the link, especially including links to anchors within a resource. Links are quite well understood by authors and users, with solid support from assistive technology, although as a downside, the distinction between links and buttons is routinely blurred by web content authors. A real advantage is that hyperlinks are primarily content. They do not put screen readers in “forms mode”, but instead can be consumed as part of a flow of text. They also support or require accessible names (typically the text node inside the <a> element).
A related semantic, the navigation role (<nav> in HTML5) might be a viable model for grouping alternative read order pathways, but the fact that it is a landmark role make it less appropriate for lower level views where high-level AT shortcuts might add noise or chatter. Perhaps we need a non-landmark version of <nav>?
Operable elements and roles such as button, so that we “hack” a browsable experience without using “browse mode”. This is a solution that works today, but breaks the tidy but rather dogmatic distinction between operable and non-operable content. Maybe we should officially “bless” the idea of using operable elements for browsing content which may have multiple ‘reading paths’?
aria-flowto - is the part of ARIA which most closely approaches the use cases that this enquiry intends to serve. The existing spec is good, as far as it goes, but has received valid criticism mainly for what it omits. In practice, there are very few implementations (user agents or ATs) that do anything interesting with this attribute. That’s a shame, but it does mean that we do not have to worry about legacy implementations in the wild.
aria-details - is a relatively recent addition to the ARIA spec, and has been suggested as a candidate for replacing aria-flowto. Some (including me) find it no better (or worse) at meeting the “alternative read order” use cases than the flawed aria-flowto attribute. Piggybacking on this attribute has the disadvantage of adding a different semantic meaning. Flowchart boxes are not each others’ “details”. A datapoint that relates to another datapoint is not a “details” relationship, it’s an alternative reading. Something quite different.
SVG Connectors - is an intriguing proposed extension to the SVG spec, which defines ways for elements to be connected. It’s very old, and didn’t go anywhere, but there are some good ideas in the proposal, not least the promise of connecting elements visually using declarative means, rather than pixel-perfect positioning.

After a deep-dive discussion, we agreed not to deprecate aria-flowto until we have a viable replacement which better serves the use cases mentioned above. We agreed that the best way to approach this was via a WICG proposal, because any solution might potentially become part of in HTML, rather than merely part of ARIA. I hope this Proposal captures the essence of the discussion, now we just have to hash it out and find something that can work.

Questions, opinions and discussion are very welcome.

jimmyfrasche · 2023-01-11

See also [css-flexbox][css-grid] Providing authors with a method of opting into following the visual order, rather than logical order · Issue #7387 · w3c/csswg-drafts · GitHub

brennanyoung · 2023-01-23

Draft spec for SVG Connectors is here.

brennanyoung · 2023-02-06

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Meaningful Sequence is Important</title>

<style type="text/css">
ol { 
    display: flex;
    flex-direction: column-reverse;
}
li {
    flex: 0 0 auto;
}
</style>
</head>
<body>
	<h1>Who is responsible for read order?</h1>
    <ol>
        <li>Accessibility is a waste of time</li>
        <li>And I refuse to believe that</li>
        <li>I can change the world.</li>
        <li>I realize this may be a shock, but</li>
        <li>“Accessibility is for everyone”</li>
        <li>Is a lie, and</li>
        <li>“Accessibility is too costly”</li>
        <li>So in thirty years, I will tell my disabled friends, family, colleagues and customers that</li>
        <li>They are not the most important thing in my life.</li>
        <li>My employer will know that</li>
        <li>I have my priorities straight because</li>
        <li>Profit</li>
        <li>Is more important than</li>
        <li>Quality</li>
        <li>I tell you this:</li>
        <li>Once upon a time</li>
        <li>People made efforts to include each other in their societies</li>
        <li>But this will not be true in my era.</li>
        <li>This is a quick fix society</li>
        <li>Experts tell me</li>
        <li>Thirty years from now, there will still be people who can't use digital technology</li>
        <li>I do not concede that</li>
        <li>I will be part of a cyberspace suitable for everyone.</li>
        <li>In the future,</li>
        <li>Inaccessible websites and apps will remain the norm.</li>
        <li>No longer can it be said that</li>
        <li>We care about access and inclusion.</li>
        <li>It will be evident that</li>
        <li>My generation is only interested in themselves.</li>
        <li>It is foolish to presume that</li>
        <li>There is hope.</li>
        <li>And all of this will come true unless we choose to reverse it.</li>
    </ol>
</body>
</html>