Understanding the Accessibility Tree — Complete Guide

In this tutorial, you will learn about Understanding the Accessibility Tree. We cover key concepts, practical examples, and best practices to help you master this topic.

The accessibility tree is a subset of the DOM that browsers expose to assistive technologies, containing only semantic information such as roles, states, properties, and names that screen readers need to interpret content.

What You'll Learn

• What the accessibility tree is and how it differs from the DOM
• How browsers construct the accessibility tree
• How ARIA attributes modify the accessibility tree
• How to inspect the accessibility tree in DevTools
• Common issues revealed by the accessibility tree

Why It Matters

• The accessibility tree determines what screen readers announce
• DOM does not equal accessibility tree — many DOM features are not exposed
• Inspecting the tree reveals accessibility issues instantly
• Understanding the tree helps debug ARIA problems

Real-World Use

• A developer inspects a custom button to verify its role is correct
• An auditor checks that decorative images are absent from the tree
• A QA tester verifies that dynamic state changes appear in the tree
• A designer confirms that visual order matches accessibility tree order

flowchart LR
  A[HTML Document] --> B[DOM Tree]
  A --> C[Render Tree]
  A --> D[Accessibility Tree]
  B --> E[All Elements]
  D --> F[Semantic Elements Only]
  F --> G[Roles, States, Names]
  G --> H[Screen Readers]

The Accessibility Tree Explained

When a browser loads a web page, it creates multiple tree structures:

1. DOM Tree — The full HTML document structure, including all elements
2. Render Tree — Visual information for painting the screen
3. Accessibility Tree — Semantic information for assistive technologies

The accessibility tree is derived from the DOM tree but includes only elements that have semantic meaning. A <div> with no ARIA attributes is present in the DOM but absent from the accessibility tree. A <button> or <h1> is present in both.

Each node in the accessibility tree has:

• Role — What kind of element it is (button, heading, link)
• Name — The accessible name (from content, alt, aria-label, or aria-labelledby)
• Description — Additional description (from aria-describedby)
• States — Current states (aria-expanded, aria-checked, disabled)
• Properties — Additional properties (aria-required, aria-haspopup)

Code Example: What Goes in the Tree

<!-- These appear in the accessibility tree -->
<nav aria-label="Main">
    <ul>
        <li><a href="/">Home</a></li>
    </ul>
</nav>
<main>
    <h1>Products</h1>
    <button aria-expanded="false">Filter</button>
</main>

<!-- These do NOT appear in the accessibility tree (no semantic meaning) -->
<div class="wrapper">
    <span class="icon" aria-hidden="true">
        <svg><!-- decorative --></svg>
    </span>
</div>

Expected output: The accessibility tree contains the nav (role=navigation), the list (role=list), the link (role=link), the main (role=main), the heading (role=heading), and the button (role=button) with its aria-expanded state. The div, span, and SVG are absent.

Inspecting the Accessibility Tree

Chrome DevTools:

1. Open DevTools (F12)
2. Go to the Elements panel
3. Click the "Accessibility" tab
4. Select an element to see its accessibility properties

Firefox DevToolsox" >}} DevTools:

1. Open DevTools (F12)
2. Go to the Accessibility panel
3. Click "Check for issues"
4. Browse the tree structure

Code Example: How ARIA Modifies the Tree

<!-- Without ARIA -->
<div>Click me</div>
<!-- Accessibility tree: (empty - div has no semantic role) -->

<!-- With role="button" -->
<div role="button" tabindex="0">Click me</div>
<!-- Accessibility tree: button, name="Click me" -->

<!-- With aria-label -->
<div role="button" aria-label="Submit form" tabindex="0">Click me</div>
<!-- Accessibility tree: button, name="Submit form" -->

<!-- With aria-labelledby overriding content -->
<h2 id="section-title">Contact Us</h2>
<div role="region" aria-labelledby="section-title">
    <!-- Content -->
</div>
<!-- Accessibility tree: region, name="Contact Us" -->

<!-- Element excluded from tree -->
<div aria-hidden="true">
    <!-- This entire subtree is hidden from accessibility -->
</div>
<!-- Accessibility tree: (nothing - entire subtree excluded) -->

Expected output: Each ARIA attribute changes the accessibility tree entry. The role adds semantic meaning. The aria-label overrides the accessible name. aria-hidden excludes the element and its children.

Code Example: Debugging with the Accessibility Tree

<!-- Debugging common issues -->
<!-- Issue: Missing label on input -->
<label>Email</label>
<input type="email">
<!-- Accessibility tree: edit (no name) - BAD -->

<!-- Fix: Proper association -->
<label for="email">Email</label>
<input type="email" id="email">
<!-- Accessibility tree: edit, name="Email" - GOOD -->

<!-- Issue: Image with no alt -->
<img src="chart.png">
<!-- Accessibility tree: img (no name) - BAD -->

<!-- Fix: Descriptive alt -->
<img src="chart.png" alt="Sales chart Q1 2026">
<!-- Accessibility tree: img, name="Sales chart Q1 2026" - GOOD -->

<!-- Issue: Button with no text -->
<button>
    <svg><!-- icon --></svg>
</button>
<!-- Accessibility tree: button (no name) - BAD -->

<!-- Fix: aria-label -->
<button aria-label="Search">
    <svg aria-hidden="true"><!-- icon --></svg>
</button>
<!-- Accessibility tree: button, name="Search" - GOOD -->

Expected output: Inspecting the accessibility tree immediately reveals missing accessible names. The tree shows "edit (no name)" for an unlabeled input, "img (no name)" for an image without alt, and "button (no name)" for an icon-only button.

Common Mistakes

1. Assuming DOM equals accessibility tree — Elements in the DOM are not automatically in the accessibility tree. Non-semantic elements like divs and spans are excluded unless given ARIA roles.
2. Forgetting that aria-hidden hides from tree — Applying aria-hidden to an element removes it and all children from the accessibility tree entirely.
3. Overriding native semantics with role — Adding role="presentation" to a heading removes it from the accessibility tree, making it invisible to screen readers.
4. Not checking the tree after dynamic updates — States like aria-expanded should appear in the tree. If they do not update, the screen reader gets stale information.
5. Redundant ARIA cluttering the tree — Adding role="navigation" to a nav element is redundant but harmless. Adding role="button" to a link changes its semantic meaning.
6. CSS display:none versus visibility:hidden — Both remove from the visual render tree, but display:none also removes from the accessibility tree. visibility:hidden keeps it in the DOM but removes from both trees.
7. Not understanding accessible name computation — The accessible name comes from a specific priority order: aria-labelledby, aria-label, then content. Not understanding this order leads to unexpected names.

Practice Questions

1. What is the accessibility tree? A subset of the DOM that contains only semantic information needed by assistive technologies, including roles, states, names, and descriptions.
2. How does the accessibility tree differ from the DOM tree? The DOM contains all HTML elements. The accessibility tree contains only elements with semantic meaning (roles, names, states).
3. How can you inspect the accessibility tree in a browser? Chrome DevTools: Elements panel, Accessibility tab. Firefox DevTools: Accessibility panel.
4. What is the accessible name computation order? aria-labelledby first, then aria-label, then element content (or alt for images).
5. Challenge: Create an HTML page with 10 intentional accessibility issues (missing labels, missing alt text, icon-only buttons, incorrect ARIA, non-semantic elements as buttons). Inspect the accessibility tree in Chrome DevTools for each issue. Document what the tree shows and fix each issue, confirming the tree now shows the correct information.

FAQ

{{< faq "Does every element in the DOM appear in the accessibility tree?" "No. Elements without semantic meaning (div, span) and those with aria-hidden="true" are excluded. Only elements that convey information to assistive technologies are included." >}}

Mini Project

Create a comprehensive accessibility tree analysis for a sample web application. Build an HTML page that includes: navigation, main content with headings and paragraphs, a form with various input types, images with and without alt text, custom widgets (tabs, accordion), decorative elements, a modal dialog, and dynamic content. Using Chrome DevTools Accessibility panel, document the accessibility tree for each section. Identify at least 5 elements that should be in the tree but are missing, and 3 elements that are in the tree but should not be. Fix each issue and verify the corrected tree. Create a visual diagram showing the DOM to accessibility tree mapping.

What's Next

Continue with Lesson 29: Inclusive Design Principles to learn design approaches that create accessible experiences for everyone.