J5.02.1accessibility treedesignresearch

Assistive technology reads the accessibility tree, not the pixels

Aliases: a11y tree · AX tree · accessible object tree

What it is

A button on a screenshot is not a button assistive technology can find. Screen readers, switch scanning, and voice control read the accessibility tree the platform exposes — not pixels, not boxes on the comp. A node that is not in the tree was never drawn, as far as AT is concerned.

Why it happens

The browser and OS fold interface objects into a thinner tree than the visual layer: what exists, what it is called, what kind it is, what condition it is in. Style is for eyes; the tree is for AT. A theme, zoom, or dark mode can rewrite every pixel while the tree stays put; conversely, perfect pixels with an empty tree are empty for AT.

Existence is decided in the tree, not on the glass. An object hidden only in style (off-screen, transparent, covered) may still be read; an object removed from structure is actually gone. What users hear or scan is a projection of this tree, not a photograph of the screen.

Studying it

Line up three artifacts: a screenshot, an accessibility-tree inspector, and the reader’s live speech. Hunt two mismatches — on the picture but not in the tree, in the tree but not on the picture.

Independent variables: whether the object enters the tree, whether it is marked decorative, style hiding versus structural hiding. Dependent variables: whether AT can locate the object, whether the announcement matches the on-screen function, whether the mismatch is existence or naming.

On desktop, the browser’s accessibility inspector; on mobile, the system inspector. “What the page looks like” is not a substitute for “what is in the tree.”

Where it stops holding

Some objects should stay out of the tree (pure decoration, duplicated visible text); absence is then correct. Canvas, game engines, and remote desktops paint the UI as a bitmap, so the tree may be a single image — the claim holds for ordinary documents, not for unbridged self-drawn surfaces. Magnifier users read pixels and do not take this tree; do not export screen-reader conclusions onto them.

Applying it

  • Every object that must be operated or understood has to appear as a node in the accessibility tree, not only in the visual layer.
  • Decorative and duplicated visible text should be removed from the tree so AT does not read a shadow UI unrelated to the task.
  • How to check: open the tree and walk every control on the primary flow. On the screenshot but missing from the tree means AT users cannot find it; in the tree but invisible on screen will be read as a ghost.

Related

  • Same group: J5.02.2 Role decides what operations a user will expect · J5.02.3 Missing name, role, or state makes a control unusable
  • Nearby: J1.01 Four Principles · J5.10 Name, Role and Value
  • Search terms: accessibility tree · assistive technology · accessible object

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/J5.02.1