Agents read your site through the accessibility tree

Of the four things Chrome's agent audit examines, one is not about AI at all and has been sitting in the standards for twenty years. It checks the accessibility tree: whether your elements have names, whether their labels are real, whether they are actually exposed.

That is the same tree a screen reader has always used. It is now also how a piece of software decides what your page contains and which control does what. The infrastructure built for blind users turned out to be the infrastructure agents needed, which is either a happy accident or an argument that the accessibility people were right the whole time.

What the tree is, in one paragraph

The browser builds a second structure alongside the visual one. For every element it records what the thing is, what it is called, what state it is in, and where it sits in the hierarchy. The rules for computing that name are a published W3C specification, Accessible Name and Description Computation, and the roles and states come from WAI-ARIA. None of this is new and none of it was invented for AI.

What is new is who reads it. Chrome's Agentic Browsing documentation lists accessibility tree integrity alongside its checks for agent tooling and layout stability, and the reason is mechanical rather than philosophical. Software that cannot see needs something to read, and this is the only structured description of a page the browser already produces.

The four failures that stop an agent cold

A div behaving as a button. It looks like a button, it responds to a click, and the tree reports a generic container with no role. A person sees a button. Everything else sees nothing actionable.

An icon with no name. The magnifying glass, the hamburger, the three dots. To an agent asked to search your site, an unnamed icon is a control whose purpose cannot be established, so it gets skipped in favor of something that can.

Placeholder text doing a label's job. The field looks labeled until focus lands in it and the hint vanishes. In the tree it was never a label to begin with, which is why WCAG has treated this as a failure for years.

Focus that scatters. Open a dialog, and if focus does not move into it and stay there, both a keyboard user and an agent lose their place in the same instant and for the same reason.

Why layout shift is on the same list

Cumulative Layout Shift looks out of place next to three semantic checks until you think about what an agent physically does. It locates a control, then acts on it. If the page is still assembling and the control moves in between, the action lands somewhere else.

People absorb this without noticing. You reach for a button, the ad loads, the button jumps, you adjust and click again. Software does not adjust. It commits, and whatever occupied that space at that moment is what got clicked. A metric everyone treated as a comfort measure is now a correctness one.

The budget argument this hands you

I have watched accessibility lose budget fights for most of my career. It gets funded when a lawsuit arrives or a deadline forces it, and the Title II rule has made that pressure real for public entities and their vendors. Otherwise it slides to the next quarter.

The same fixes now also determine whether a buyer's agent can complete anything on your site. That is a second business case for work you already owed, and I would use it, while being honest that it is not why the work is right. I wrote the longer version of that argument in accessibility as an AI architecture requirement.

The practical move is small. Run the audit, read the accessibility failures rather than the total, and fix the controls on the paths that matter: contact, search, booking, checkout. Those are the paths an agent will be sent down, and they are usually the shortest list on the site.

Common questions