aom

Accessibility Tree

Problem statements

Consistency between user agents

The Core-AAM and HTML-AAM and, potentially in future, CSS-AAM each describe some parts of the process of mapping from a source language to platform accessibility APIs, typically in the form of a mapping table.

However, while Core-AAM has some language around conditions under which elements must be mapped into the accessibility tree, it is unable to provide a complete set of conditions under which elements are not mapped into the accessibility tree, leading to inconsistencies between browsers, which assistive technology vendors are forced to work around.

Effect of new web features on accessibility APIs

We lack a process for web APIs to describe their intended effect on accessibility APIs.

For example, display: contents in CSS causes an element “not [to] generate any boxes”. This was intended not to affect “semantics” (ref), but because in practice browsers tend to base the accessibility tree on the CSS box tree, this created a bug in most browsers where nodes with this property were not exposed to the accessibility tree.

Since there exists no standard for how the accesibility tree is built, there was no understanding of this potential impact, and the issue was only discovered after the feature shipped and bugs were filed on various browsers.

Ideally, spec authors would be able to have some understanding of how their feature may impact accessibility tree generation, and, where necessary, be able to explicitly describe how it should impact accessibility tree generation.

Web Platform Testing

Once web spec authors are able to specify how their features should impact the accessibility tree, web platform tests will be needed in order to verify implementations.

A JavaScript-based API independent of platform API differences would streamline the testing process.

Web page testing

Web page authors and authors of accessibility validation tools alike are interested in methods for making assertions about how a web page is expressed to assistive technology APIs.

To date, this has only been possible using various proprietary and open source inspection tools, by testing directly with assistive technology (which naturally will always be a required step in accessibility testing) or by writing tools which read information from platform APIs.

Developer documentation, debugging and education

Various browsers provide tools to inspect the accessibility information exposed for a particular DOM node, potentially with a view of the browser’s notion of the generic accessibility tree:

However, developers are unable to link this information to any definitive explanation of what is being represented.

Potential audience for an Accessibility Tree spec

User agent implementers

The spec should document consensus reached between user agent implementers and assistive technology implementers, to allow user agent implementers to implement a consistent accessibility tree.

Authors of other specs

Authors of web platform features should consider the intended impact on the accessibility tree of their feature.

Authors of documents like HTML-AAM, Core-AAM etc may wish to refer to a generic specification for the accessibility tree.

Any specification which aims to provide programmatic access to the accessibility tree will need a definition of the accessibility tree to refer to.

Developers

Web Platform Test authors, web page authors and testing tool authors may all find an accessibility tree specification informative.

Lifecycle

Since the web platform is a moving target, adopting a living or evergreen standard model will probably make the most sense.

What needs to be specified?

Platform-independent semantic properties

Tree inclusion/exclusion principles

See https://w3c.github.io/aria/#tree_inclusion

Mapping between generic tree and platform APIs

Open questions/assumptions

Acknowledgements

Thanks to the following individuals for comments/input so far: