Skip to content

Latest commit

 

History

History
183 lines (138 loc) · 8.26 KB

accessibility-tree.md

File metadata and controls

183 lines (138 loc) · 8.26 KB
Raw

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.

Related documents/prior work

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

  • What needs to be normative and what doesn't?
  • How close to a 1:1 mapping between "generic" tree and platform APIs is acceptable?
  • Exactly which web platform tree should the accessibility tree be based on? - Suggestion:flattened DOM tree (post Shadow DOM distribution) plus CSS generated content
    • Any other things to consider?
  • aria-hidden removes things from the accessibility tree - unless it is focusable
  • display:none and visibility:hidden
    • Firefox keeps them in the tree but marks them invisible, WebKit removes them. If we required that these stay in the accessibility tree, Blink and WebKit could modify their code to let you walk these nodes for AOM phase 4, but still remove them from the platform accessibility tree on some or all platforms.
  • Accessibility tree order should match focus order.
  • How should flexbox ordering affect accessibility tree ordering?
  • Tables - the accessibility tree is in thead/tbody/tfoot order even if that doesn't match the DOM order
  • Image maps - the accessibility tree contains a duplicate of the image map subtree each time it occurs
  • <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.
  • What's the root of the tree? The document? The body? What if both the document and body have ARIA attributes? What if there are multiple bodies?

Acknowledgements

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

  • Dominic Mazzoni, Google
  • Ian Pouncey, The Paciello Group
  • Joanmarie Diggs, Igalia
  • Léonie Watson, The Paciello Group
  • Melanie Richards, Microsoft
  • Rossen Atanassov, Microsoft
  • Ryosuke Niwa, Apple