Accessibility Tree

The accessibility tree is not a 1:1 copy of the Document Object Model. It is a filtered representation that omits purely presentational elements—such as <div> and <span> with no semantic role—and retains only nodes that convey meaning to assistive technology.

• Exclusion: Elements with display: none or visibility: hidden are pruned entirely.
• Inclusion: Semantic elements like <button>, <input>, and <nav> are promoted as actionable or navigational objects.
• Text Nodes: Raw text strings are surfaced as leaf nodes with computed accessible names.

This parallel structure ensures that screen readers and AI crawlers receive a high-signal, low-noise representation of the interface.

Every node in the accessibility tree must resolve to a human-readable accessible name and, optionally, an accessible description. The browser computes these strings using a prioritized algorithm defined by the Accessible Name and Description Computation specification.

• Priority Order: aria-labelledby → aria-label → native labeling (e.g., <label> for inputs) → title attribute → inner text content.
• Concatenation: aria-labelledby can reference multiple IDs, concatenating their text in order.
• Hidden Content: Text from elements with aria-hidden="true" is excluded from the computation.

This deterministic naming mechanism is critical for AI agents that rely on programmatic identifiers rather than visual cues.

Each element in the accessibility tree is assigned a role that defines its purpose and interaction model. The WAI-ARIA specification defines a strict taxonomy of roles, categorized into:

• Abstract Roles: Conceptual base classes (e.g., widget, structure) used only for ontology; never assigned to elements directly.
• Widget Roles: Interactive components like button, checkbox, slider, and tab.
• Document Structure Roles: Organizational elements like article, list, img, and heading.
• Landmark Roles: Navigational regions like banner, main, navigation, and complementary.

Native HTML elements have implicit roles (e.g., <main> maps to role="main"), while custom widgets require explicit role assignment via the role attribute.

Beyond static roles, the accessibility tree exposes dynamic states and relational properties that communicate the current condition of interactive elements to assistive technologies.

• States: Transient conditions such as aria-expanded, aria-checked, aria-selected, and aria-current that update in real-time as users interact with the UI.
• Properties: Persistent characteristics like aria-required, aria-readonly, and aria-haspopup that define constraints and capabilities.
• Live Regions: Elements marked with aria-live push asynchronous updates to the tree, enabling screen readers to announce dynamic content changes without focus movement.

AI agents can monitor these state changes to understand application logic flow without visual rendering.

The accessibility tree preserves parent-child and ownership relationships that define the structural and functional context of each node.

• Ownership: A list role owns listitem children; a tablist owns tab elements. These relationships are programmatically enforced.
• Flow Relationships: aria-flowto and aria-controls establish non-hierarchical connections between disparate nodes.
• Described-by & Labelled-by: aria-describedby and aria-labelledby create associative links that cross-cut the visual DOM structure.

This relationship graph allows AI parsers to reconstruct the logical topology of a complex application independently of its visual layout.

The browser translates the accessibility tree into platform-specific Accessibility APIs—such as UI Automation (Windows), NSAccessibility (macOS), and ATK/AT-SPI (Linux)—that serve as the communication protocol between the application and assistive technology.

• Abstraction Layer: Developers interact with HTML and ARIA; the browser handles the low-level API translation.
• Event Propagation: State changes in the tree trigger platform-level events that notify screen readers of updates.
• Performance Boundary: A bloated or deeply nested accessibility tree increases serialization overhead, directly impacting assistive technology responsiveness.

This bridge is the final delivery mechanism that makes semantic intent actionable for end-user assistive tools.