The accessibility tree

The browser builds more than the DOM.

It also creates an accessibility tree for assistive technology. This tree contains the roles, names, values, and states that matter for interaction.

Consider this button:

<button type="button">Save route</button>

The accessibility tree exposes a button with the name “Save route.” The browser gets both pieces from the native element.

Other examples follow the same pattern:

• nav creates a navigation landmark
• h2 creates a level-two heading
• img creates an image whose name comes from alt
• input gets its name from its associated label
• a with href creates a link

This is why semantic HTML matters even when two elements look identical.

Inspect the tree

Open DevTools and inspect an element. Look for an Accessibility pane.

Select a button, link, image, and heading. Check the role and accessible name for each one.

If an image has the wrong name, fix its alt text. If a form control has no name, fix its label. Change the HTML source rather than patching the accessibility tree with unnecessary ARIA.

Elements hidden with display: none are normally removed from this tree. aria-hidden="true" also hides content from assistive technology, but leaves it visible. Do not use it on meaningful or focusable content.

The accessibility tree is a useful debugging view. It shows what your HTML communicates beyond the screen.

A div with a click handler is not a button in this tree unless you add ARIA and keyboard behavior. A native button already exposes the right role and name. I reach for semantic elements first and ARIA second.

When a control shows an empty name in the Accessibility pane, the fix is almost always in the HTML: add a label, fix alt, or put visible text inside the element.

Run this check on your practice page before you call it done. If you cannot explain each interactive element’s name from the source alone, fix the markup.