The Accessibility Tree: What Screen Readers Hear
How the browser builds a parallel tree from your DOM.
The Accessibility Tree: What Screen Readers Hear is a free Web Accessibility Academy lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Web Accessibility Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
A Parallel Tree
The browser turns your DOM into a second structure called the accessibility tree. It is the version assistive tech actually reads.
Built From Your DOM
The accessibility tree is built straight from your HTML. Good semantics in, a rich tree out; div soup in, an empty, useless tree out.
Nodes Have a Role
Each node carries a role that says what it is: button, heading, link, list. A real button gets the button role with no effort from you.
Nodes Have a Name
Every node also has an accessible name, the text a screen reader speaks. For a button it is usually the visible label inside it.
<button>Save changes</button>Nodes Have State
Interactive nodes expose a state too, like checked, expanded, or disabled. This is how a user hears that a box is already ticked.
Role, Name, State, Value
So each node boils down to role, name, state, and value. That tiny package is everything a screen reader needs to announce an element.
Hidden Things Drop Out
Anything hidden with display none or aria-hidden is pruned from the tree. If it is not in the tree, a screen reader cannot reach it.
<span aria-hidden="true">decorative</span>Pixels Are Not in the Tree
Visual styling like color and size never enters the accessibility tree. A screen reader user gets meaning and structure, not your layout.
Bad Markup, Broken Tree
A clickable div lands in the tree as a generic node with no role and no name. The user hears nothing useful, even though it looks like a button.
You Can Inspect It
Browser DevTools show the live accessibility tree for any element. It is the fastest way to confirm what a screen reader will actually announce.
Markup Is the Source
The big lesson: your markup is the source of the tree. Fix the HTML and the tree fixes itself, no extra patching required.
Quick Check
Let us test what screen readers hear.
Recap
The accessibility tree is your DOM distilled to role, name, state, and value. Fix the markup and the tree follows. Hidden things drop out. 🎉
Frequently asked questions
Is the “The Accessibility Tree: What Screen Readers Hear” lesson free?
Yes — the full text of “The Accessibility Tree: What Screen Readers Hear” is free to read here on the web, and the Web Accessibility Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Web Accessibility Academy course, upgrade to CoddyKit PRO.
What will I learn in “The Accessibility Tree: What Screen Readers Hear”?
How the browser builds a parallel tree from your DOM. You practise Web Accessibility Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Web Accessibility Academy?
No prior experience is required. Web Accessibility Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “The Accessibility Tree: What Screen Readers Hear” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Web Accessibility Academy lesson?
Yes. Every Web Accessibility Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Tags Have Meaning: Why div Soup Fails
- Text Elements: Paragraphs, Lists, and Emphasis
- The Accessibility Tree: What Screen Readers Hear
- Native vs Custom: When to Reach for a Real Element