skip to content

What is the accessibility tree, and how do a control's name, role, value and state describe it to someone who cannot see it?

level: middleimportance: must knowfreq 70%

answer

  1. Assistive technology does not read pixels
  2. A parallel structure the platform derives
  3. Decorative content is pruned from it
  4. Four facts describe every exposed node
  5. One Level A criterion covers all four

basics

~20 s

The accessibility tree is a parallel structure the platform derives from an interface and exposes to assistive technology. Each node carries a role, an accessible name, a value and states - enough for a non-visual user to identify and operate a control.

solid answer

~50 s

Assistive technology never reads your interface directly. The platform builds an **accessibility tree** from it - a filtered, flattened structure in which every exposed element becomes a node - and screen readers, voice-control engines and switch access all read that tree. Each node answers four questions: its **role** (what kind of thing this is), its **accessible name** (which one it is), its **value** (what it currently holds) and its **states** (expanded, checked, disabled, busy). Announce those four and a user who cannot see the screen knows a control exists, what it does, which one it is, and what happened when they used it. The success criterion *4.1.2 Name, Role, Value* (Level A) is exactly this contract. Decorative and hidden content is pruned from the tree, which is why hiding something visually and removing it from the tree are two different operations.

code

pseudocode · 5 lines
pseudocode
NODE
  role   : button
  name   : Buy single ticket
  value  : (none)
  state  : enabled, not pressed

go deeper

for a junior

Be ready to say that assistive technology reads a separate structure the platform builds from the interface rather than the visuals, and to name the four facts a node carries about one control.

for a middle

Explain how the tree is derived and pruned: which elements produce nodes, which are dropped as decorative or hidden, and why the tree ends up much smaller than the structure it came from.

for a senior

An interviewer at this level expects you to debug from the tree outward. A user reports a control is missing and you reason about ghost nodes, pruned nodes and nodes whose state went stale, not about the layout.

for a principal

Own the argument that the tree is a product surface with its own contract. Teams that treat it as a developer tool ship interfaces whose announced description drifts from the real one, and the remedy is a review habit rather than another scanner.

## The structure assistive technology actually reads An interface, on any platform, exists twice. There is the thing you can see - laid out, painted, animated - and there is a second structure the platform derives from it and hands to assistive technology: the **accessibility tree**. A screen reader, a voice-control engine, a switch-access driver and a braille display all read that second structure. None of them reads pixels, and none of them reads the source you wrote directly. That single fact explains most of the discipline. When a user reports that a control is not there, the question is never what the screen looks like; it is what the node for that control says. And when a change is invisible in the tree - a purely visual state that was never written down anywhere the tree can see - nobody who depends on the tree learns that anything happened. The tree is **derived**, not authored. The platform walks the interface's own structure, decides which elements are exposed and which are pruned, computes a node for each exposed one, and keeps that node current as the interface changes. Two consequences follow. First, the tree is normally much smaller than the structure it came from: containers that exist only for layout, purely decorative graphics, and content explicitly marked as hidden produce no nodes at all. Second, everything in it is computed from something you declared - so when a node is wrong, the cause is upstream, in what the interface said about itself. ## The four facts a node carries Each exposed node answers four questions about one control. Read them out in order and you have, near enough, what a non-visual user hears. | Fact | The user's question | Example | | --- | --- | --- | | **Role** | What kind of thing is this? | a button, a checkbox, a tab, a heading, a landmark | | **Accessible name** | Which one is it? | Buy single ticket | | **Value** | What does it hold right now? | the text entered in a field, a slider's position | | **State** | What is it doing right now? | checked, expanded, disabled, busy, selected | Roles come in families that matter to navigation: **landmark** roles mark the large regions of a screen, structural roles mark headings, lists and tables, and widget roles mark the things a user can operate. The **accessible name** is the short identifying string; a longer and optional **accessible description** may sit beside it for supplementary help. **Value** applies only where a control holds one. **State** is the volatile part, and the part most often left stale. The success criterion *4.1.2 Name, Role, Value* (Level A) is precisely this contract: for every user-interface component the name and role must be programmatically determinable, states and values the user can set must be programmatically settable, and changes to any of them must be notified to assistive technology. It sits at Level A - the floor, not an enhancement. ## Why four facts and not just the text Picture a fare screen with five controls that all read Select. A sighted user resolves them by position: the one beside the departure time, the one under the fare table. A user who cannot see them has no such context. What they have is a linear walk through the tree, node by node, so each node has to be self-describing. - **Role without a name** announces button five times over: the user knows something is operable and cannot tell which one it is. - **Name without a role** produces a phrase with no indication it can be operated; it reads as prose and gets skipped. - **Name and role without state** hides the outcome: the user activates a control, a panel opens, and nothing in the tree says so. - **All four, kept current** gives Select, button, collapsed - enough to decide, act and confirm the result. ## Three ways the tree goes wrong 1. **Ghost nodes.** Something removed from view but not from the tree stays reachable. A non-visual user walks into controls that, for everyone else, are gone. 2. **Missing nodes.** Something meaningful is presented as decoration and gets pruned. It is on the screen and simply does not exist for assistive technology. 3. **Stale nodes.** A name, value or state was correct when the screen was first built and was never updated afterwards. The tree now describes a screen that no longer exists. The practical consequence for testing is that a node's **presence** and a node's **truth** are different properties. Automated inspection can tell you a node exists and carries a name; only a human operating the control can tell you the name is the right one and the state still matches reality. That boundary is why the tree is worth understanding as a model rather than memorising as a checklist: it is the surface your users experience, and it is the only place their experience can be read back.

  • An element is invisible on screen but still present in the accessibility tree. What does that cost a non-visual user?
    They meet a control that, for everyone else, is gone. They can focus it, activate it and get no visible result, and they have no way to tell it apart from a working control. Removing something from view and removing it from the tree are separate acts, and doing only the first leaves a ghost that wastes the user's attempt and undermines their trust in the rest of the screen.
  • Why is the accessibility tree usually much smaller than the structure the interface was built from?
    Because it is derived by filtering. Containers that exist only to arrange layout contribute nothing a user needs to know, purely decorative graphics are marked as such, and content explicitly hidden from assistive technology is dropped. What survives is the set of things worth describing: regions, structure and operable controls. A tree that is nearly as large as the interface usually means decoration was never marked as decoration.
  • What does a node with a role but no accessible name give a user?
    Almost nothing useful. The user learns that something operable is there and cannot learn which one, so a row of five such nodes is announced identically five times. Role tells them what kind of thing it is; the name is the only fact that distinguishes one instance from another. A role without a name is a common defect precisely because it looks correct in a structural review.

It is the cast list rather than the costumes and the set. Assistive technology reads who is on stage, which one each is, and what each is doing right now - never the visuals.

saying these in an interview costs you the question

  • Says assistive technology reads the visual layout directly
  • Calls the accessibility tree a debugging view rather than a real surface
  • Believes hiding something visually also removes it from the tree
  • Cannot name what a node exposes beyond its text
  • Assumes the tree updates itself when a purely visual state changes