Tables and accessibility

The accessibility tree

See how semantic HTML becomes a smaller tree of roles, names, values, and states that assistive technology can navigate.

8 minute lesson

~~~

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.

SEMANTIC HTMLNAVBUTTON: SAVEIMG ALT="ROUTE MAP"ACCESSIBILITY TREENAVIGATIONBUTTON “SAVE”IMG “ROUTE MAP”
Good HTML gives assistive technology useful roles and names.

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.

Lesson completed