ARIA and the accessibility tree

Definition: WAI-ARIA (Accessible Rich Internet Applications) supplies roles, which identify interface types, and attributes that describe elements to assistive software such as screen readers. The accessibility tree is a hierarchy of accessible objects through which a browser exposes interface information, including an element's role and accessible name, its label for assistive technology.

Key facts

• The W3C's WAI-ARIA specification describes the accessibility tree and the Document Object Model (DOM), the page's object representation, as parallel structures.
• W3C's naming guidance recommends using visible text for accessible names when suitable text exists.
• W3C's Read Me First guidance explains that adding an ARIA role supplies neither keyboard behavior nor styling.
• As of 17 October 2026, Microsoft's Playwright MCP documentation describes browser automation through structured accessibility snapshots.

How does the browser expose roles and states?

The WAI-ARIA Recommendation describes browsers conveying information to the operating system's accessibility API, the interface through which assistive software reads it. Accessible objects expose states and properties; for example, aria-pressed indicates a toggle button's pressed state.

The specification recommends a native language feature whenever it provides equivalent accessibility. For HTML, this means retaining suitable built-in elements when adding ARIA. A custom element with a button role requires the author to implement the expected interaction: the Authoring Practices Guide specifically identifies JavaScript keyboard handling as part of that responsibility.

How do labels become accessible names?

W3C's Accessible Names and Descriptions guidance distinguishes an element's name from its description. A description adds information such as input instructions; the name identifies the control's purpose.

The guide provides this example:

<button type="button" aria-label="Close">X</button>

The accessible name is Close. On a button, aria-label replaces descendant content as the source of its name. A visible text label is preferable when suitable text can be included in the design. The guide also documents aria-labelledby, which references other elements and takes precedence over aria-label in name calculation.

States convey separate information. The Read Me First guide includes this native button with an ARIA state:

<button aria-pressed="false">Mute</button>

Here, Mute supplies the name and aria-pressed="false" supplies the toggle state.

How can a software agent use this information?

Microsoft's Playwright MCP server documentation provides a concrete example: a browser automation server enables language models to interact with pages through structured accessibility snapshots. Its browser_snapshot tool captures the current page's accessibility snapshot. Its click tool accepts an exact element reference from a page snapshot as a target.

In this workflow, exposed interface semantics are input to browser automation. A button's accessible name helps describe the control an agent encounters. This is a documented use of accessibility information by a particular tool.

How is the accessibility tree checked?

Google's Chrome DevTools accessibility reference, updated 28 May 2026, documents inspection through the Elements panel. Selecting an element and opening the Accessibility tab exposes its ARIA attributes and computed accessibility properties.

The Show accessibility tree toggle replaces the DOM view with a full-page accessibility tree. Expanding and selecting nodes reveals their details under Computed properties. This allows inspection of the resulting accessibility information alongside the underlying element.

Related terms

• Semantic HTML
• Rendered DOM
• Image alternative text
• Agentic search

FAQ

Does every button need an explicit ARIA label?

The W3C naming guide lists buttons among elements that obtain their names from descendant content by default. You can use suitable visible button text as the name.

Does aria-hidden affect descendants?

The WAI-ARIA specification says browsers should exclude elements with aria-hidden="true" and their descendants from the accessibility tree. Setting aria-hidden="false" on a descendant does not override that ancestor setting.

Is inspecting the tree sufficient accessibility testing?

W3C's Read Me First guidance calls for interoperability testing with the browser and assistive technology combinations relevant to the audience. You should test those combinations when implementing its patterns.

Sources

1. W3C, "Accessible Rich Internet Applications (WAI-ARIA) 1.2", 6 June 2023
2. W3C WAI, "Providing Accessible Names and Descriptions", undated
3. W3C WAI, "Read Me First", undated
4. Microsoft, "Playwright MCP", undated
5. Google, "Accessibility features reference", 28 May 2026

---

Check how a page reads to answer engines. Open the GEO score analyzer