Lesson 2 of 30

The Accessibility Tree and How Screen Readers Actually Work

Q: A screen reader user reports that a custom dropdown component 'doesn't work' — nothing is announced when they focus it, even though it looks and behaves correctly for mouse users. How do you actually investigate this, step by step?

A strong answer covers: States clearly that a screen reader queries the accessibility tree, not the DOM or CSS directly — so the investigation should start there, not with a visual re-check; Names a concrete diagnostic tool: Chrome DevTools' Accessibility pane (or equivalent) to inspect the element's actual computed name, role, and state; Identifies the likely root cause pattern: a div or custom element with visual styling but no real role/name/focusability, since visual correctness doesn't imply accessibility-tree correctness; Proposes a concrete fix direction: either use a native interactive element, or add the correct ARIA role/name/state and keyboard handling if no native equivalent exists.

A screen reader never looks at your CSS. It queries a separate tree the browser builds from the DOM, and understanding that tree is the difference between guessing at accessibility and actually diagnosing it.

13 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A div is styled with CSS to look exactly like a toggle switch and has a click handler attached. What is most likely true about its accessibility tree node?

It's likely a generic node with no meaningful role, no accessible name, and not keyboard-focusableThe browser infers a 'switch' role automatically from the CSS styling that visually resembles a toggleThe onclick handler automatically makes it focusable and gives it a button role

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on The Accessibility Tree and How Screen Readers Actually Work

What interviewers actually ask about this, and what a strong answer has to cover.

A screen reader user reports that a custom dropdown component 'doesn't work' — nothing is announced when they focus it, even though it looks and behaves correctly for mouse users. How do you actually investigate this, step by step?

A strong answer covers

States clearly that a screen reader queries the accessibility tree, not the DOM or CSS directly — so the investigation should start there, not with a visual re-check
Names a concrete diagnostic tool: Chrome DevTools' Accessibility pane (or equivalent) to inspect the element's actual computed name, role, and state
Identifies the likely root cause pattern: a div or custom element with visual styling but no real role/name/focusability, since visual correctness doesn't imply accessibility-tree correctness
Proposes a concrete fix direction: either use a native interactive element, or add the correct ARIA role/name/state and keyboard handling if no native equivalent exists

Likely follow-ups

The Accessibility pane shows a role of 'generic' with no name. What are the two general ways you could fix that, and what's the tradeoff between them?
How is this different from a case where the element is simply display: none and therefore correctly absent from both trees?

The plain-language idea

Alongside the DOM, the browser builds a second tree: the accessibility tree. It's derived from the DOM, but it isn't the DOM — it strips out everything assistive technology doesn't need (styling, layout, most structural nesting) and keeps only what a screen reader actually queries: for each node, its name (what gets announced), role (what kind of thing it is — button, link, heading, list), state (checked, expanded, disabled), and value (a slider's current number, an input's current text).

This single fact resolves a lot of confusing behavior once you know it: a screen reader doesn't read your page visually and it doesn't parse your CSS. It queries the accessibility tree. That means two things are true at once, and they're genuinely independent of each other:

A visually hidden element (display: none, or an off-screen "sr-only" utility class) can still be fully announced, if it's present in the accessibility tree — this is exactly how visually-hidden helper text for screen readers works on purpose.
A visually present, even visually obvious, interactive-looking element can be completely silent to a screen reader — invisible in the tree — if it has no accessible name or role. Styling something to look like a button doesn't put a "button" node in the accessibility tree; only real button semantics (native <button>, or a correctly-implemented ARIA equivalent) do that.

Visual presentation and accessibility-tree presence are two separate systems. Getting one right says nothing about the other.

See it in a real thing: inspecting the tree directly

The DOM vs. the accessibility treeStep 1 of 4

The DOM and the accessibility tree are two separate trees built from the same page — a screen reader only ever queries the second one.

The reliable way to know what a screen reader will actually announce isn't to guess from reading markup — it's to look at the accessibility tree directly. Chrome DevTools has this built in: open the Elements panel, select an element, then open the Accessibility pane in the sidebar. It shows the computed name, role, and state for that exact node, generated the same way a screen reader would consume it.

<!-- Looks like a button. Isn't one to the accessibility tree. -->
<div class="btn" onclick="deleteItem()">Delete</div>

<!-- Real button: name "Delete", role "button", focusable, keyboard-operable -->
<button onclick="deleteItem()">Delete</button>

Both divs render identically. Inspect the first one in DevTools' Accessibility pane and there's often no meaningful node there at all — generic, no role, no interactive semantics. Inspect the second and you'll see name: "Delete", role: "button" — exactly what a screen reader needs to announce "Delete, button" and let a user activate it.

What people usually miss

Watch out

A screen reader queries the accessibility tree, not the DOM and not your stylesheet. Debugging "why didn't this get announced" by reading CSS or component JSX in isolation skips the layer that actually matters — go look at the computed accessibility tree itself.
Visually hidden does not mean accessibility-tree-hidden, and vice versa. display: none removes an element from both the visual render and the accessibility tree. An "sr-only" class that clips visually but keeps the element rendered keeps it in the accessibility tree — that distinction is exactly how visible-only and screen-reader-only content are built on purpose.
A missing accessible name is often invisible in a visual review, because visual review can't see the tree at all. A component can look completely finished and still generate an empty or generic accessibility-tree node — the bug is only visible by actually inspecting the tree, not by looking harder at the screen.
DevTools' Accessibility pane is a diagnostic tool, not a nice-to-have. Guessing what a screen reader will announce from reading source code is unreliable in exactly the cases that matter most — this is the tool that replaces guessing with an answer.

Why this matters in interviews

"How would you actually verify what a screen reader announces for this component, without a screen reader installed?" tests whether a candidate knows the accessibility tree exists as a distinct, inspectable layer — naming Chrome DevTools' Accessibility pane as a concrete diagnostic step is a strong, specific signal over a vague "I'd test it with a screen reader" answer.