accessibility-tree.md

Standardising the accessibility tree

Shortlink: http://bit.ly/a11y-tree

Goals

• Determine potential editors for a general accessibility tree spec
• Determine intended audience for spec
• Determine initial location for work
• Discuss intended lifecycle
• Determine basic principles of tree walking and property computatino
• Determine relationship to existing documents
  • Core-AAM
  • HTML-AAM
  • AccName
  • ATTA-API

Potential editors

Intended audience

• User agent implementors
• Authors of other specs
  • New features should explain impact on tree
  • AOM intends provide programmatic access to tree
• Web Platform Test authors
• Web developers?
• Testing tool authors?

Initial location

• ARIA?
• AOM?
• New WICG group?

Intended lifecycle

• Various HTML/CSS features need to describe their impacts on the tree
• There should be a process of negotiation between feature authors, UA implementors, and AT implementors to determine the accessibility tree design for each feature
• How should HTML/CSS specs refer to the accessibility tree spec?

Basic principles

Tree traversal

• Not necessarily a 1:1 mapping between "generic" tree and platform APIs, but should be as close as possible
• Tree is based on flattened DOM tree (post Shadow DOM distribution) plus CSS generated content
  • Any other things to consider?
• aria-hidden removes things from the accessibility tree
• 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.
• Flexbox 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?

Node properties

• Similarly, not necessarily a 1:1 mapping between "generic" tree and platform APIs, but should be as close as possible