What Is the Accessibility Tree? The invisible structure of a website

For people who use a screen reader, for example, a different representation is especially important: the accessibility tree.

It doesn't primarily describe how a website looks, but what its elements mean and how they can be used.

What is the accessibility tree?

The accessibility tree is a structured representation of a website, generated by the browser.

The browser focuses on information that matters for operating and understanding the website.

A complex web page might, in simplified form, produce a structure like this:

Much of the information about layout, colors, or visual design plays no role here.

Instead, the focus is on the meaning of each individual element.

From HTML to the accessibility tree

In simplified terms, you can picture the path like this:

The browser analyzes the website and makes relevant information available in a form that assistive technologies can use.

Three pieces of information matter most for this:

Role: What is the element?

Name: What is the element called?

State: What state is it in?

This means a website isn't just read aloud. Users can understand its structure and interact with it purposefully.

A simple example

Take a normal HTML button:

From the HTML element alone, the browser already recognizes:

A screen reader can therefore announce, for example, "button, Get in touch".

This is a good example of why semantic HTML matters so much for accessibility.

A real <button> element already carries meaning. A generic <div>, by contrast, initially doesn't.

We explain more about this in our article "Semantic HTML: Why Good HTML Code Matters for People and Machines".

Not every HTML element ends up in the accessibility tree

The DOM – the document structure of a website generated by the browser – and the accessibility tree are not identical.

A web page can, for example, contain numerous <div> elements that are only needed for layout and visual design.

Such elements may carry no meaningful information of their own for a screen reader.

The accessibility tree therefore reduces the website to the information that's relevant for assistive technologies.

An extensive HTML structure thus becomes a representation far more focused on meaning and usability.

What role does ARIA play?

Sometimes, plain HTML semantics aren't enough.

Take a button that opens a menu:

This is a button named "Menu".

But it doesn't automatically know whether the associated menu is currently open or closed.

This is where ARIA can provide additional information:

As a result, the state can also appear in the accessibility tree:

When the menu is opened, the application changes the value to:

ARIA thus adds information that then becomes available to assistive technologies through the browser's accessibility interfaces.

We explain exactly how this works in more detail in our article "What Is ARIA? Accessible Websites, Explained Simply".

Why is the accessibility tree so important for screen readers?

A screen reader isn't meant to simply read a website from top to bottom.

Users need to be able to orient themselves on a page. They can, for example, deliberately:

• jump from heading to heading,
• access navigations,
• browse through links,
• operate forms,
• select buttons, or
• recognize the state of interactive elements.

To make this possible, the website has to describe, in unambiguous technical terms, what each of its elements means.

The accessibility tree plays a central role in exactly this.

A website therefore has, in a sense, two views

Put simply, you could say:

A sighted visitor, for example, perceives the following:

The semantic representation, by contrast, contains information like:

Both describe the same website – but in completely different ways.

What happens with bad HTML?

Problems arise when the visible appearance and the technical meaning diverge.

A developer might, for example, style a <div> so it looks exactly like a button and behaves like one when clicked.

To a sighted user, this is initially almost impossible to tell.

In the accessibility tree, however, the following information may be missing:

This is a button.

Similar problems can occur with navigations, forms, dialogs, accordions, or tabs.

That's why good accessibility doesn't start with a screen reader.

It starts with a website's HTML structure.

How do I check my website's accessibility tree in Chrome, Firefox, and Safari?

Modern browsers come with their own developer tools that let you inspect a website's accessibility information directly. This lets you check, for example, whether a supposed button is actually recognized as a button, what name a link has for a screen reader, or whether an expanded menu correctly reports its state.

Google Chrome

In Chrome, first open the developer tools (DevTools) – for example by right-clicking an element and choosing "Inspect", or on the Mac with ⌘ + ⌥ + I.

Then:

1. Open the Elements panel.
2. Select an element on the website.
3. Open the Accessibility pane.
4. There you can check the computed role, the accessible name, ARIA attributes, and other accessibility properties.
5. Chrome also offers a full accessibility tree view that lets you browse the semantic structure of the entire page.

In current versions of Chrome, the full accessibility tree view is built directly into the Elements tools. Switching between the DOM and the accessibility tree is especially useful: it lets you directly compare which HTML element produces which semantic information.

Mozilla Firefox

Firefox has an especially clear Accessibility Inspector.

You can open the developer tools, for example, by right-clicking and choosing "Inspect Element". Then select the Accessibility pane.

Firefox displays the accessibility tree as its own tree structure. For individual elements, it shows, among other things:

• Role,
• Name,
• State,
• Value,
• relationships to other elements, and
• relevant accessibility attributes.

It's also handy that you can right-click directly on the web page and choose "Inspect Accessibility Properties". Firefox then jumps to the corresponding element in the accessibility tree.

Firefox can also visualize the tab order. This lets you check the order in which links, buttons, and form fields are reached when navigating with the keyboard.

Apple Safari

Safari also provides accessibility information through the Web Inspector. If the developer tools aren't enabled yet, you can turn them on in Safari under Settings → Advanced, via the option for web developers. The Web Inspector can then be opened, for example, with ⌥ + ⌘ + I.

In the Elements panel, you can select a DOM element. In the details or Node pane, Safari shows the accessibility data for the selected element.

Unlike Firefox, Safari presents accessibility inspection in a more element-by-element way. Still, this is very useful for a quick check: you can, for example, see what role and accessible name Safari determines for a button, link, or form field.

The Web Inspector also offers Accessibility Audits, which let you check for common issues automatically.

What should I pay attention to?

For an initial test, you don't need to understand every technical property. For important elements, a few simple questions are enough to start with:

• Is a heading actually recognized as a heading?
• Is a button recognized as a button?
• Does the button or link have an understandable name?
• Are the navigation and main content recognizable as such?
• Do form fields have understandable labels?
• Are states like "open", "closed", "selected", or "disabled" reported correctly?
• Is the order logical when navigating by keyboard?

Comparing the visible website, the DOM, and the accessibility tree side by side makes many issues very quickly understandable.

One thing is important, though: inspecting the accessibility tree doesn't replace a full accessibility test. A website should also actually be tested with the keyboard and – at least on a spot-check basis – with a screen reader.

What does the accessibility tree have to do with search engines?

The accessibility tree is, first and foremost, a technical foundation for accessibility and assistive technologies.

It shouldn't therefore be understood as an SEO tool.

Even so, there's an important common thread:

Accessibility, search engines, and automated systems often all benefit from clearly structured content.

A clean heading hierarchy, understandable link text, correctly marked-up forms, and semantic HTML all help describe a web page's meaning more clearly at a technical level.

That's one of the reasons why technical accessibility and high-quality website development overlap in so many places.

Why the accessibility tree matters for AI agents

AI adds a further dimension to this topic.

AI agents are increasingly expected to not just read web pages, but operate them too.

An agent might, for example, be given the task:

Search the website for TYPO3 support and open the contact form.

To do this, it needs to recognize which elements are links, buttons, navigations, or input fields.

A purely visual analysis would, for example, have to work out:

A semantic representation, by contrast, can directly provide information like:

That's far more unambiguous.

Browser-based AI agents can therefore use semantic information and accessibility interfaces to understand and operate web pages efficiently.

That doesn't mean, however, that every AI automatically uses the accessibility tree when visiting a website.

Nor does it mean that a good accessibility tree automatically leads to better rankings in AI search.

The connection runs deeper than that:

A website that describes its content and functions in clear technical terms is easier for automated systems to understand and operate.

Semantic HTML, ARIA, and the accessibility tree belong together

The three concepts can be clearly distinguished from one another:

An example:

HTML says: this is a button.

ARIA adds: the associated section is closed.

The accessibility tree makes this information available in a form assistive technologies can use.

That's exactly why these three concepts complement one another.

What does this mean for TYPO3 websites?

In TYPO3, a large part of this technical structure is generated automatically by templates, content elements, and extensions.

A technically well-built TYPO3 website should therefore, among other things, make sure that:

Conclusion

The accessibility tree is invisible to most visitors of a website. For people who use assistive technologies, however, it matters a great deal.

It doesn't put a website's appearance at the center, but its structure, meaning, and usability.

The accessibility tree thus illustrates very clearly why modern web development is more than just good design.

A good website doesn't just have to look good. It also has to be technically understandable.

Semantic HTML lays the foundation for this. ARIA adds important information. The accessibility tree makes this semantics usable for assistive technologies.

And in a web where automated systems, alongside people, increasingly interact with websites, clear technical semantics becomes all the more relevant.