Your accessibility tree is now your agent API
The accessibility tree used to be a concern for screen-reader users alone. Now it is the interface AI agents use to operate your site. Same fixes, higher stakes: an unnamed control is a control no agent can click.
Last updated July 12, 2026AI agents do not look at your rendered pixels; they read the accessibility tree, the browser’s structured model of every control’s role, name, and state. If a button has no accessible name, an agent cannot find or click it, the same way a screen reader could not announce it. Google’s Agentic Browsing audit checks this directly, which means web accessibility just turned from a compliance checkbox into a distribution requirement.
- The accessibility tree gives each element a role (what it is), a name (what to call it), and state (checked, expanded). Agents target elements through it.
- The usual failure is an icon button or a
<div onclick>with no accessible name: invisible to agents and screen readers alike. - Fixes are ordinary accessibility work: semantic HTML, real labels,
aria-labelon icon buttons, correct roles and states. - This is the on-page half of agent readiness. Doing it well also lifts your Lighthouse Accessibility score and helps every human visitor.
An AI agent trying to use your site does not see the polished interface you designed. It sees the accessibility tree: the browser’s structured, text-only model of what is on the page, what each element is, and what it is called. For twenty years that tree mattered mainly to screen-reader users, and plenty of sites quietly ignored it. Now it is the API that browsing agents operate your site through, which means the accessibility work you may have skipped just became a distribution problem. Here is what the tree is, why agents depend on it, and the concrete fixes that make you usable.
01 · The modelWhat the accessibility tree is
A structured representation the browser derives from the DOM and ARIA attributes, in which every relevant element has a role (button, link, checkbox, heading), an accessible name (the text used to refer to it), and state (checked, expanded, disabled). Assistive technologies and, increasingly, AI agents read this tree instead of the rendered pixels to understand and operate a page.
Think of it as the machine-readable label on every part of your interface. A visual button is, in the tree, a node that says “role: button, name: Save”. If those two facts are present and correct, any machine (a screen reader, an agent) knows there is a Save button and can act on it. If they are missing, the button might as well not exist.
02 · From compliance to distributionWhy agents read it, not the screen
An agent could, in theory, take a screenshot and run vision models over it. In practice that is slow, expensive, and error-prone, so agents prefer the tree: a clean semantic list of the page’s controls and content. This is the same reason screen readers use it. The tree is the honest, structured version of your UI, and it is what a machine reaches for first.
That reframes accessibility entirely. It used to be a compliance task justified by “it is the right thing to do” and the occasional legal requirement. Now the same tree decides whether an AI agent can complete a purchase, book a slot, or fill a form on your site. Accessibility stopped being only about who you let in and became about who can use you, humans and machines alike.
An unnamed button is invisible to a screen reader and invisible to an agent. Accessibility was never only compliance; it is the interface every non-visual visitor uses, and now that includes the ones spending money.
03 · Three thingsWhat the audit actually checks
Google’s Agentic Browsing accessibility-tree check reuses Lighthouse’s existing accessibility machinery, focused on three things that matter to a machine:
| Facet | The question | Typical failure |
|---|---|---|
| Names and labels | Does every control have an accessible name? | Icon buttons, unlabelled inputs |
| Tree integrity | Are roles correct and the structure coherent? | <div onclick> acting as a button |
| Visibility | Is the tree free of mislabelled or wrongly hidden nodes? | Real content behind aria-hidden |
None of these is exotic. They are the everyday failures of a UI built for sighted mouse users and never checked for anything else.
04 · Concrete workThe fixes that matter
In rough order of impact:
- Use semantic elements. A
<button>is a button in the tree automatically; a<div>is not. Prefer<button>,<a>,<nav>,<main>,<label>, and real headings over styled<div>s. This one habit fixes most role and integrity problems for free. - Name every control. Visible text names a control automatically. For icon-only buttons, add an
aria-label. For inputs, use a real<label for>(a placeholder is not a label). - Expose state. For custom widgets (toggles, accordions, tabs), set the ARIA states an agent reads:
aria-expanded,aria-checked,aria-selected. A toggle that never reports its state leaves an agent guessing. - Do not hide real content.
aria-hidden="true"on something interactive removes it from the tree entirely. Reserve it for decoration.
The single highest-leverage change, the named icon button:
<!-- No role, no name. An agent cannot find or target this. -->
<div class="icon-btn" onclick="save()">💾</div>
<!-- Real button with an accessible name. The agent can call "Save". -->
<button type="button" onclick="save()" aria-label="Save">💾</button>Not sure what an agent can and cannot reach on your page?
Nilkick checks the signals that decide whether an agent can discover and act on your site, then shows what is missing, as part of a free launch-readiness report.
05 · See what the agent seesHow to inspect your own tree
You do not have to guess. In Chrome DevTools, select any element in the Elements panel and open the Accessibility pane to read its computed role and accessible name; if the name is blank, that is your bug. For the whole page, turn on the full-page accessibility tree view to browse the structure a machine actually receives. Then run Lighthouse: both the Accessibility category and the Agentic Browsing audit will point at the specific elements missing a name or role. Fix what they flag, and you have made your site legible to every screen reader and every agent at once.
Worth being clear on scope: a clean accessibility tree is the on-page half of agent readiness. It makes your page operable. It does not make an agent show up, and it is separate from the discoverability signals (llms.txt, crawler rules) that help an agent find you in the first place.
Common questions
<svg> or an emoji in a <div>) with no aria-label, or a clickable <div> with no button role, has no accessible name. A human guesses from the icon; an agent and a screen reader get nothing. Naming your controls is the single highest-impact fix.Get your free launch-readiness score
See what else is between your product and its first real users. Nilkick scores your readiness and hands you the map. Free, no login.
https:// optional · no account · we don't email you
A checklist to pass the Agentic Browsing audit
A step-by-step checklist to pass Google's Agentic Browsing audit: fix the accessibility tree, stop layout shift, ship llms.txt, then weigh WebMCP.
Why layout shift breaks AI agents (CLS beyond humans)
An AI agent clicks where a control was a moment ago; if your layout shifts, it misses. Why CLS is in the Agentic Browsing audit, and how to hold your page still.
What is agentic browsing?
Agentic browsing is an AI agent operating your site on a user's behalf, not just reading it. What the term means in 2026, and why Google now scores it.