Thread by @cookiecrook

WebKit’s presentational list heuristics for accessibility have come up as a topic recently. Starting a thread with some of the background. 1/20

Some people think this behavior is in VoiceOver or Safari, but it's in WebKit, the rendering engine used by Safari and most anything else that renders a web view on Mac or iOS. 2/20

The change of behavior was driven by feedback from VoiceOver users. In the mid-to-late 2000s, trends in web development were to use divs for everything. The anti-pattern was commonly referred to as “div-itis.” 3/20

As a reaction to div-itis, developers started using lists for anything that could possibly be grouped, leading to a problem we referred to as “list-itis.” Lists of lists, single item lists, irrelevant lists, etc. 4/20

Web developers were doing this in the name of Semantic Markup™, fighting for the user. But the end result is that screen reader users were being shouldered with too much meaningless auditory overhead. 5/20

And they let us know. 6/20

I reviewed lots of emails, bug reports, and feedback from VoiceOver users at the time (2014?) that said things like: “the Web has too many lists” or “all I hear when reading news sites is ‘list, two items … end of list, list 4 items…’ and I don’t care about all the lists.” 7/20

The HTML Design Principles “Priority of Constituencies” section states: “In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.” w3.org/TR/html-design… 8/20

Something similar had been done before with tables… Every engine includes heuristics to determine whether tables are used as data tables. The heuristics are imperfect, but well refined. I haven’t heard of a false positive on WebKit’s table heuristic implementation in years. 9/20

Here’s the source of the WebKit isDataTable() implementation. Did you know—among other style-based checks—it looks for zebra-striped tables? github.com/WebKit/webkit/… 10/20

The list heuristics to determine role relevance are more complicated than most web authors assume, but in general the principle is this: If all of the styles that make it “list-like” have been removed, it’s no longer relevant to convey it as a list. 11/20

Stated another way, if a sighted user doesn’t need to know it’s a list, why would a screen reader user need to know or want to know? 12/20

Stated another way, if the visible list markers (bullets, image markers, etc.) are deemed by the designers to be visually burdensome or redundant for sighted users, why burden screen reader users with those semantics? 13/20

According the the Priority of Constituencies quoted above, the choice to use a UL is irrelevant here, in some cases, even misguided. 14/20

Of course, heuristics are imperfect, so authors have the ability to explicitly override the heuristically determined role by adding role="list". (Contrary to some reports, you don’t need to use role=listitem on every LI, or use a CSS hack. The list role is sufficient.) 15/20

Anyway, after the WebKit change, all the “too many lists” feedback from VoiceOver users stopped. It worked. It’s been years, and I’m still reasonably confident we made the right choice… for the users. 16/20

Most web developers are oblivious to the behavior. It’s only a subset of accessibility-focused web developers that even notice, and the authoring cost for a false negative is trivial: add an explicit role to the list. 17/20

On a tangent: a lot of CSS is used to compute the accessibility tree. Many people think it’s only display: none; and visibility: hidden; but dozens, if not hundreds, of style characteristics contribute. 18/20

It’s not just for screen readers either. The same accessibility trees are used by VoiceOver, Switch Control, Voice Control, Hover Text, and more, including the new Full Keyboard Access on iOS. It’s never been as simple as “expose the DOM to screen readers.” 19/20

WebKit is very open to changes in the heuristics that determine whether something is a “layout list.” If it results in fewer false negatives and zero more false positives across the broader Web, please make a suggestion or submit a patch. webkit.org/new-ax-bug 20/20 /end

Note: @yatil also has a pretty good write-up of this topic. Check out his take at: yatil.net/posts/2019/01/…