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.

Paste this into your AI design or build tool to reproduce this issue's visual system.

Design a single self-contained HTML page as a mid-century cinema poster program, Saul Bass cut-paper modernism. The content is a daily design-news briefing: a top nav, an issue masthead with number, date, and read time, a hero headline with a one-line deck, a boxed art-direction note, numbered sections of linked news items with one or two sentences of context each, one pullquote, a monospace prompt block, a sources list, and a colophon.

Treatment: program paper #EFE7D1 with deeper #E2D8BC panels; a cut-paper composition anchored to one hero corner built from simple geometry (a cobalt lozenge, a tomato circle, an ink bar); a vertical monospace strip in the margin carrying the issue number; section markers as spelled-out numerals ONE, TWO, THREE in Spartan caps, each prefixed by a tomato bar; the pullquote framed by thick black bookend bars above and below; takeaway cards reversed out in ink #171615 with a tomato pin; tomato #D8401C punctuation accents and cobalt #26456E secondary.

Type: League Spartan caps for display with a tomato period on the headline, PT Serif for body, Fraunces italic for asides, DM Mono for credit-block captions.

Guardrails: body text at least 18px with line height 1.6 or more, prose in the body face and never in monospace, line length 60-75 characters, WCAG AA contrast on every surface, hover and focus states on real links, decoration in the margins and panels rather than under running prose, no fake readable text in images, and no default AI styling (no purple-blue gradients, no glow, no pill-shaped everything). Cut-paper shapes are flat fills, no gradients or bevels.

Works in v0, Lovable, Bolt, Figma Make, Beaver Builder AI, or as a Claude / GPT system brief.

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