Skip to main content
WCAGrules
Quick navigation

Glossary · Accessibility term

Accessibility tree

The accessibility tree is a second structure the browser builds alongside the DOM, holding one object for every part of your page that has to be exposed to assistive technology. Four things on each object do most of the work. Its role, meaning what it is. Its accessible name, meaning what it is called. Its description, meaning anything extra attached. And its state. Pressed, expanded, checked, disabled. There is more on there besides, including how objects relate to one another and what can be done to them, so treat those four as the ones you will be fixing rather than the whole record. Assistive technology works from that tree, by way of the operating system's own accessibility interface, rather than from your CSS or your markup directly. So if the tree is wrong, the page is broken for those readers however good it looks on screen.

In practice

Where the DOM says a div with these classes, the tree says a button, named Submit, currently disabled. It is genuinely smaller than the DOM, because an object is only created where something has to be exposed. It is bigger in one direction, though, because it takes in the browser's own interface as well as your document. That is why a screen reader can move from your page up to the address bar and back again.

You can look at it, and it takes about thirty seconds. Chrome's developer tools carry an Accessibility tab showing the computed name, role and properties for whichever element you selected, plus a toggle that replaces the whole DOM tree with the accessibility tree. Firefox has an Accessibility Inspector doing the same job and showing relations and actions besides. It is the quickest way to find out what the browser is exposing, and that is what most confusing bugs turn out to be about.

Three ways of hiding something look similar and behave differently. Hiding something with display:none or visibility:hidden takes it out of the tree, and the browser is required to leave it out. The aria-hidden attribute is a request rather than a requirement, and it removes the element along with everything inside it. That is the trap. Put it on a wrapper and everything inside disappears from the tree while staying focusable, so a keyboard still reaches controls the screen reader will not announce. A presentational role is the reverse again, stripping the element's own semantics and leaving its contents where they were.

Why it matters

Most confusing accessibility bugs stop being confusing the moment you look at the tree. A button announced as nothing but button has an empty name there. An element somebody can still tab to but cannot hear has been taken out of the tree while staying in the DOM. A control announced as the wrong thing has a role you gave it. The tree is where every one of those answers lives, because it is what the browser decided to say about your page, and no amount of correct-looking markup outranks what it decided.

Why aria-label sometimes does nothing

Some roles are barred from carrying a name at all, and a plain div or span is among them. ARIA tells authors not to put aria-label or aria-labelledby on one, and the name computation ignores it if you do. So the attribute is there, nothing in the browser complains, and the tree shows no name. Give the element a real role, or use a real element.

Where this shows up on the site

Related terms

Knowing the word is the easy part.

Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.

Run the free scan

Go somewhere useful

Find tools, resources and your workspace.

29 destinations