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.
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.
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 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.
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.
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 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.
Web Platform Test authors, web page authors and testing tool authors may all find an accessibility tree specification informative.
Since the web platform is a moving target, adopting a living or evergreen standard model will probably make the most sense.
See https://w3c.github.io/aria/#tree_inclusion
aria-hidden removes things from the accessibility tree - unless it is focusabledisplay:none and visibility:hidden
thead/tbody/tfoot order even if that doesn’t match the DOM order<select> - the DOM tree has just <select> with a child of <option>, but on every platform the AX tree ends up with a node in-between, the "menu" role.Thanks to the following individuals for comments/input so far: