A long-underestimated layer
The accessibility tree has long been discussed as an accessibility issue in the strict sense. That is already enough reason to treat it seriously: people who use assistive technologies depend on this layer to understand and operate the interface.
But in the agentic era, this layer takes on an additional role.
Google explains in Build agent-friendly websites that modern agents combine several modalities: DOM, accessibility tree and visual rendering. The accessibility tree provides a structured list of interactive roles, names and states. In other words, it acts as a functional map of the page.
What the tree reveals
Visual rendering says: “this is what appears on screen”.
The DOM says: “this is how elements are structured”.
The accessibility tree says: “this is what the elements are meant to do”.
That third signal is crucial. An agent may see a rectangular shape with text. But if the element is not exposed as a named button, it has to infer its function. Every inference adds risk.
Accessible names are intent signals
A button named “Submit” is usable. A button named “Submit diagnostic request” is clearer.
A field with a placeholder “Name” may be understood visually. A field connected to a real <label> is more robust.
A clickable icon without an accessible name requires guessing. An icon with an explicit name states its action.
These details determine action quality. They are not cosmetic.
The most costly errors
In audits, the same errors come back often:
- buttons without accessible names;
- clickable icons without descriptions;
- fields without labels;
- form errors not connected to fields;
- menus whose expanded or collapsed state is not exposed;
- modals without clear role or focus management;
- elements hidden visually but still present in the tree;
- visible elements absent from the tree.
These issues first harm humans. They also weaken agents that rely on this layer.
Why this is not an official API
The accessibility tree is not a commercial API dedicated to agents. It should not be instrumentalized at the expense of real accessibility.
But in practice, it behaves like an implicit API: a structured browser-generated representation that exposes what the interface allows users to do.
That is why an accessible site is generally easier for agents to interpret.
How to integrate it into a method
In the agentic readiness audit, the accessibility tree is compared with two other layers: visual rendering and hydrated DOM.
The question is not only: “does the tree exist?”
The question is: “does the tree describe the same interface that humans see and the DOM exposes?”
That coherence is what makes action more reliable.
Conclusion
The Accessibility Tree is becoming strategic again because it forces the interface to be explicit.
In the short term, it improves accessibility and frontend quality. In the medium term, it improves the ability of AI agents to understand and operate the site. In both cases, the result is the same: an interface that is more readable, more reliable and more responsible.