The accessibility tree is the new sitemap.

The headline news of the spring is structural, not visual. Chrome 146 shipped an early preview of WebMCP behind a flag, opening the door for any website to expose itself as a structured set of tools that browser agents can call. The page used to be a destination; with WebMCP the page becomes a small server, and the agent on the other side of the address bar is its first reader.

WebMCP defines two surfaces. The declarative API lets a site annotate ordinary HTML forms with the actions an agent is allowed to take — submit-order, add-to-cart, book-room — in the markup itself. The imperative API hands the agent a JavaScript handle for the dynamic interactions that forms cannot describe. The spec is being co-developed with Microsoft and incubated through the W3C Web Machine Learning community group, and the broader rollout is expected to land alongside Google I/O on May 19 and 20.

The agent's first read is structural

Underneath the rollout sits a quieter truth that Google's own developer-advocacy team finally put on the page last month. The web.dev guide Build agent-friendly websites describes three ways an agent perceives a site — screenshots, the DOM, and the accessibility tree — and says plainly that the third is the one agents prefer. The tree is cheap to parse, semantically clean, and immune to the visual noise of CSS. When the screenshot is ambiguous, the agent falls back to the tree. When the markup is sloppy, the screenshot becomes the only signal, and the agent slows down. Every styled div that should have been a button taxes the entire interaction.

The new tooling stack rearranges around that fact. Cloudflare's Browser Run gives agents headless sessions on the edge with full DOM access and record-replay. Browserbase has shipped Stagehand v3 in the same window, rewritten to talk directly to the Chrome DevTools Protocol and run 44% faster than its previous automation layer. The pipes have widened; the surface those pipes carry is the structural layer, not the rendered pixels.

The most useful frame this week comes from a new study from UC Berkeley and the University of Michigan, accepted at CHI 2026, that put numbers on what the web.dev guide implies. The team ran a computer-use agent against a battery of sixty everyday tasks and held the page constant while changing the agent's input modality. Three runs, three different reads of the same room.

The full paper, A11y-CUA: Characterizing the Accessibility Gap in Computer Use Agents, is sharper than the numbers suggest. The agents in the study were not blocked by the assistive conditions because the conditions were hard; they were blocked because the sites underneath them assumed a full mouse, a full viewport, and a sighted reader. The same conditions that exclude blind and low-vision human users also exclude agents that lean on the accessibility tree. The audience overlaps. The remediation overlaps too.

The three reads, ranked

The Chrome team's framing is the cleanest. An agent looking at your site can take a screenshot, parse the rendered DOM, or read the accessibility tree distilled from both. Screenshots are slow and expensive, the DOM is verbose and ambiguous, the tree is the semantic summary the page would expose to a screen reader. Modern agents fuse all three, but they reach for the tree first because it returns the smallest set of high-signal nodes — roles, names, states, the actual interactive surface of the page.

Two patterns follow. The first is that the things teams have spent a decade learning to do for accessibility — semantic landmarks, real button elements, label tags tied to inputs, visible focus rings — are now the same things the agent benchmark rewards. The second is that anything that makes the rendered page look right while corrupting the tree — a transparent overlay catching clicks, a div role="button" with no tabindex, a layout that shifts the action button into a new position on every product page — is now a tax the agent pays every time it visits.

Audit the room before the surface

The quick win for designers is to open Chrome DevTools' accessibility tree pane alongside the Figma board. The two artifacts read the same components in different languages. Where the Figma frame says Buy now button, the tree should say button, name "Buy now". Where the frame shows a labelled input, the tree should show a single node with the label string inlined. When the names disagree, the agent disagrees too, and the cheapest place to find that disagreement is in the dev panel, not in production logs.

A five-person product studio in Bristol has been running what they call a two-track review on every component PR since March. One track is the design review every team already has — the visual diff, the spacing audit, the motion check. The other track is new. They open the rendered component in a headless browser session, walk a tab-only agent through it, and read the accessibility tree out loud against the Figma annotations. The two tracks meet at the end and have to agree before the PR merges.

The agent is not a stricter reader than a human. It is a blunter one — and that bluntness is what makes it a useful design partner. — § 03 Workflow

What the tab-only agent finds

What the second track catches is rarely a missing label. It is the carousel whose tabs are reachable in order 3 / 1 / 2 because the visual designer rearranged the slides in CSS without touching the DOM. It is the icon button whose only name is the file name of an SVG sprite. It is the dropdown whose menu items render in a portal that the agent cannot find because the trigger never announces aria-controls. The studio's lead now calls these visible only to humans failures — and reports the agent track catches roughly two per PR, almost none of which the human reviewers flagged.

The roles, in one cast list

The cast is small and the schedule is short. A designer annotates the Figma board with the role each component is supposed to play in the tree. A coding agent writes the component and produces a screenshot, a markup snapshot, and a printed accessibility tree as part of the PR description. A reviewer agent walks the live page with keyboard-only input and reports the friction points back to the PR thread. A human reviewer reconciles the two readings and either merges or asks for changes. Four readers, two tracks, one component — and the design org owns the contract that says what good looks like in both tracks.

The prompt below is what the Bristol studio gives its coding agent before any component PR. It runs as a side-task on the same branch as the build, attached as a comment on the PR. The clauses that earn their keep are 2 and 4 — the first forbids the agent from passing the audit on visual grounds, the second insists on a single named action per interactive node.

You are the accessibility-tree auditor. You do not write code in this pass.
You read the rendered component, print its accessibility tree, and report.

For each interactive node in the tree:

1.  Quote the role and the accessible name verbatim. If the name is empty,
    that is the finding — do not infer what it should be from the
    surrounding markup.

2.  Do not consult the screenshot to fill in missing names. The agent
    you are auditing for cannot, either. If a node would be unusable
    from the tree alone, that is the finding.

3.  Walk the tab order from start to finish. Report any node that is
    reachable visually but missing from the tab order, and any node
    whose tab position contradicts its visual position by more than
    one step.

4.  For every node whose role is "button" or "link", check that exactly
    one verb-phrase action is named. "Buy now" is one action. "Buy now /
    Save for later" is two and should be two nodes.

5.  Close with a single line: pass, soft-fail, or hard-fail.
    Soft-fail means a reader who relied on the tree would be slowed.
    Hard-fail means they would be blocked.

Do not propose fixes in this pass. Hand the report to the build agent
on the same PR thread and let it write the diff.

The line that pays for the rest is clause 2 — do not consult the screenshot to fill in missing names. Without it, the auditor agent quietly imputes the name Buy now onto an unlabelled icon button because the rendered page made the action obvious, and the report comes back clean. With it, the same unlabelled icon button gets surfaced as a hard-fail, the build agent renames the node on the next pass, and the component ships with a real accessible name for the first time.

What is funny about the week is that none of this is new. Semantic HTML, the accessibility tree, the discipline of naming the interactive surface of a page — that work has been carried for two decades by accessibility advocates who were told it was a compliance cost. The agent rollout has now revealed it as the most-trafficked layer of the web. The same constraints that made a site usable for a blind reader on a screen reader make it legible to a coding agent on a tree-parser, because the surface they read is the same surface. The audience widened. The remediation list did not.

The cinema poster on the page above is fitting in the way it is supposed to be fitting. A great Bass poster works because the structural image carries the argument before the type ever loads — and a great agent-ready page works for the same reason. The aesthetic layer can rotate every day, the way this publication's idiom does. The semantic layer underneath cannot. It is the part that has to be right whether anyone looks at the screenshot or not.

1. WebMCP is available for early preview Chrome · spring 2026
2. Build agent-friendly websites web.dev
3. When to use WebMCP and MCP Chrome for Developers
4. A11y-CUA — characterising the accessibility gap in computer-use agents CHI 2026 · Berkeley & Michigan
5. Browser Run — give your agents a browser Cloudflare
6. Agents, meet the Figma canvas Figma
7. Introducing the new v0 — sandbox runtime, Git panel, production deploys Vercel
8. Meta's Immersive Web SDK ships an agentic workflow Road to VR · May 2026
9. MolmoWeb — an open agent for automating web tasks Ai2
10. AI agents as users Nielsen Norman Group