FrontendHaltAccessibility tree
Understand how HTML becomes roles, names, states, and relationships consumed by assistive technologies.
WHAT YOU WILL BE ABLE TO DO
Learning outcomes
- Explain accessibility tree in plain language.
- Connect the behavior to the underlying browser or framework model.
- Implement the core pattern and reason through edge cases.
- Answer common follow-ups without relying on memorized phrases.
01Overview
The accessibility tree is a structure derived from the DOM — pruned of purely presentational nodes — that assistive technology actually reads. Each node exposes a role, an accessible name, and a state (expanded, checked, disabled, and so on).
02Mental model
The first rule of ARIA: if a native HTML element or attribute already has the semantics you need, use it instead of re-implementing it with a div and ARIA attributes. ARIA supplements gaps in native semantics; it doesn't replace them, and it never adds real keyboard behavior on its own.
03Examples
<!-- Fragile: no keyboard support, no accessible role by default --><div onclick="submit()">Submit</div>
<!-- Correct: focusable, keyboard-activatable, role="button" for free --><button onclick="submit()">Submit</button>04Check understanding
Why does adding role="button" to a div still leave it worse than a real <button>?
role="button" only fixes the exposed role; it doesn't add focusability, Enter/Space key activation, or the disabled state handling a native button provides automatically.
DDConcept deep dives
Deep dive 1
Browsers map DOM semantics to platform APIs
The browser derives an accessibility tree containing roles, accessible names, states, values, and relationships consumed by screen readers and other tools. CSS and ARIA can affect this mapping, so two visually identical elements may expose completely different interfaces. Inspect computed accessibility properties instead of assuming source attributes produce the intended result.
- A native element contributes semantics and behavior automatically.
- Some presentational wrappers may be omitted from the accessibility tree.
- Browser and assistive-technology combinations can differ at the edges.
Deep dive 2
Accessible names follow an algorithm
A control's name may come from aria-labelledby, aria-label, an associated label, element content, alt text, or host-language rules in a defined precedence. Adding an aria-label can override useful visible text. The result should be concise, specific, and aligned with the visible interface.
- Icon-only buttons need a programmatic name.
- Repeated controls need context such as the affected item.
- Descriptions supplement a name; they do not replace one.
Deep dive 3
Hidden, visible, and focusable states must agree
display:none and hidden normally remove content visually and from accessibility APIs. aria-hidden removes a subtree from accessibility exposure but does not remove it visually or from keyboard focus. A focusable descendant inside aria-hidden content creates a severe mismatch: keyboard users can reach something assistive technology cannot identify.
- Use a proven visually-hidden style when text should remain available to assistive technology.
- Make closed overlays inert or unmounted, not merely transparent.
- Test keyboard behavior and the accessibility tree together.
QAInterview questions and model answers
Attempt each answer aloud before opening it. The model answer shows the depth and precision expected in an interview; it is not a script to memorize.
Intermediate · Conceptual · 1 min · Question 1What is the accessibility tree?Open model answer
Model answer
It is a platform representation derived from DOM semantics, attributes, styles, and browser rules that exposes roles, names, states, and relationships to assistive technology. It is related to but not identical to the DOM.
Open question page →Intermediate · Conceptual · 1 min · Question 2How is an accessible name calculated?Open model answer
Model answer
The algorithm considers sources such as aria-labelledby, aria-label, associated labels, element content, and host-language rules in a defined order. Adding multiple names does not concatenate them arbitrarily; inspect the computed accessibility properties.
Open question page →Intermediate · Conceptual · 1 min · Question 3What does aria-hidden do?Open model answer
Model answer
aria-hidden=true removes an element and its descendants from the accessibility tree but does not visually hide them or prevent focus. Never leave focusable interactive descendants inside an aria-hidden subtree.
Open question page →Intermediate · Conceptual · 1 min · Question 4What is the first rule of ARIA?Open model answer
Model answer
If a native HTML element provides the semantics and behavior you need, use it instead of recreating it with a role. Native controls carry keyboard, state, form, and platform behavior that ARIA alone does not add.
Open question page →Intermediate · Conceptual · 1 min · Question 5How do display:none and visibility:hidden affect accessibility?Open model answer
Model answer
Content removed with display:none or visibility:hidden is normally excluded from the accessibility tree as well as visual interaction. Visually-hidden CSS uses a different technique to keep meaningful text available to assistive technology.
Open question page →Intermediate · Conceptual · 1 min · Question 6How do you test accessibility semantics?Open model answer
Model answer
Start with semantic code review and automated checks, inspect roles and names in browser accessibility tools, test complete keyboard flows, and use representative screen readers for important journeys. No single tool proves accessibility.
Open question page →Advanced · Conceptual · 1 min · Question 7What is an accessibility role?Open model answer
Model answer
It describes an element's interaction or structural purpose to assistive technology, such as button, heading, navigation, or status. Role must agree with behavior.
Open question page →Advanced · Conceptual · 1 min · Question 8How do aria-labelledby and aria-label differ?Open model answer
Model answer
aria-labelledby references existing element text and generally has naming precedence, while aria-label supplies a string directly when no suitable visible label exists.
Open question page →Advanced · Conceptual · 1 min · Question 9What is an accessible description?Open model answer
Model answer
It provides supplementary help or error context beyond the concise accessible name, often from aria-describedby or host-language description mechanisms.
Open question page →Advanced · Conceptual · 1 min · Question 10Does an automated accessibility score prove compliance?Open model answer
Model answer
No. Automated checks detect rule-based issues but cannot judge complete keyboard workflows, understandable content, correct announcements, or usability with assistive technology.
Open question page →SCScenario questions
Scenario 1
An icon-only delete button is announced only as 'button'.
- Determine the control's specific action and affected item.
- Provide a programmatic name through visible or visually hidden text, or aria-label.
- Mark a decorative icon hidden from assistive technology.
- Verify the computed name and confirmation flow.
Reveal worked answer
The button needs a contextual name such as 'Delete Quarterly report'. The SVG is decorative and aria-hidden. If deletion is destructive, the interaction also needs clear confirmation or undo behavior, and focus must move logically after the row disappears.