Frontend Beauty
ESC

Type to search the knowledge base.

What is the Accessibility Tree

How browsers expose roles, names, and states to assistive tech — relationship to DOM/CSS, and how to debug with DevTools.

beginner3 min read
  • accessibility
  • what-is

Browsers don’t hand the raw DOM to screen readers. They build an accessibility tree (or expose platform accessibility APIs derived from it): a simplified structure of roles, names, descriptions, states, and properties. If something is missing from that tree, assistive tech users can’t perceive or operate it — even if pixels look fine.

Docs: MDN Accessibility tree, Chrome a11y tooling.

DOM vs accessibility tree

HTML DOM  +  CSS (visibility, display)  +  ARIA
                 ↓
         Accessibility tree
                 ↓
     Platform APIs (VoiceOver, NVDA, …)

Hidden content (display: none, visibility: hidden, hidden, aria-hidden="true") is generally excluded. Off-screen visually hidden text can remain included if done correctly — that’s how screen-reader-only labels work.

Nodes carry semantics

A typical node exposes:

Field Example
Role button, link, heading
Name “Save changes”
Description “Opens a dialog”
State expanded, checked, disabled
Value textbox contents

See accessible names computation, ARIA roles overview.

Why engineers should care

  1. Testing Library queries use roles/names from this model.
  2. Broken ARIA produces wrong tree nodes.
  3. CSS can accidentally remove semantics (display: contents pitfalls historically).
  4. Debugging “SR won’t read X” starts in the tree, not in random ARIA spam.

How to inspect

Chrome/Edge: Elements → Accessibility pane (Computed properties: Name, Role, …).

Firefox: Accessibility Inspector.

Safari: Develop → Show Web Inspector → Nodes → Accessibility.

Walk the tree like a DOM inspector. Compare against what VoiceOver announces.

Pruning and presentational roles

<table role="presentation">…layout leftovers…</table>

role="presentation" / none strips semantics. Use carefully — you can wipe needed structure.

<svg aria-hidden="true">…</svg>

Decorative graphics pruned intentionally.

Common tree bugs

Symptom Cause
Button has no name Icon-only without label
List not a list Divs without list roles/markup
Duplicate announcements Redundant aria-label + text
Empty main Content outside landmarks / hidden

Interview out-loud answer

“The accessibility tree is the browser’s semantic view for AT: roles, names, states. CSS and ARIA affect what gets included. I debug with DevTools accessibility panes and fix names/roles rather than adding random ARIA.”

Shadow DOM and iframes

Shadow DOM encapsulates nodes; a11y exposure depends on browser and whether slots flatten correctly. Cross-origin iframes are separate documents — you can’t fix their tree from the parent. Prefer not putting critical flows in opaque third-party iframes when you must guarantee a11y.

Extra practice

Write a minimal demo in a scratch file or the playground: one happy path, one failure path, and one boundary input. If you cannot exhibit a bug that the pattern prevents, you do not own the concept yet — re-read the primary docs linked below and tighten the example until the failure is obvious.

Notes from real codebases

Teams that succeed here keep the rules mechanical: lint where possible, CI for the rest, and a short human checklist for what automation cannot see. Document exceptions with an owner name and a removal date so “temporary” escapes do not become permanent architecture.

Further reading

Related guides