The Accessibility Tree Is Your Newest Public API

For a decade, accessibility was the work that slipped. It lived at the bottom of the backlog, resurfaced during compliance audits, and got patched with just enough ARIA to quiet the linter. The economic argument never landed because the affected users were a minority whose churn never showed up in a dashboard anyone was paged about.

Then browser agents arrived, and the economics inverted overnight. Products like ChatGPT's browsing mode, Claude's computer use, and the wave of Playwright-MCP-based automation don't see your pixels. They read the browser's accessibility tree — the same semantic structure screen readers have consumed for twenty years. Every unlabeled button, every div masquerading as a link, every custom dropdown that doesn't expose its state is now invisible not just to blind users but to the agents your business partners are integrating against. A decade of deferred accessibility debt just became integration debt, and integration debt has paying customers attached.

The uncomfortable part isn't the technology. It's the incentive flip: teams that ignored screen-reader users for years are about to fix those exact bugs in a sprint, the week an agent partnership breaks. Whether that makes you cynical or hopeful, it changes how you should think about your markup. Your accessibility tree is no longer an assistive-technology detail. It's a public API surface — unversioned, undocumented, and already in production.

Agents Read the Tree, Not the Screen

When a browser renders your page, it builds two parallel structures. The render tree drives pixels. The accessibility tree drives semantics: a pruned hierarchy where each node carries a role (button, link, textbox), an accessible name, a state (checked, disabled, expanded), and a description. Screen readers consume it through platform APIs. Browser agents consume it through the Chrome DevTools Protocol or framework snapshots.

The reason agents standardized on the tree is token economics, not idealism. A raw DOM dump of a typical page runs 15,000+ tokens. A screenshot pushed through a vision model costs thousands of tokens and misreads dense layouts. An accessibility-tree snapshot of the same page often fits in 200–400 tokens. Microsoft's Playwright MCP server sends the model a YAML-formatted tree where each interactive element gets a numbered reference ID; the agent acts by saying "click ref 12," not by hunting for CSS selectors. Browser-use, Claude's read-page action, and most of the MCP browser servers shipped over the past two years work the same way. Google's Project Mariner runs a hybrid vision-plus-tree approach, and even there the tree carries the semantic load.

This has a blunt consequence: if an element doesn't surface properly in the accessibility tree, the agent cannot reliably find it. Some tools are stricter still — Vercel's agent-browser resolves references by walking the tree and matching on role and name, so an element without a proper role never gets a reference at all. It isn't hard to click. It does not exist.

Your Div Soup Is Returning 404s Now

Map the classic accessibility defects onto agent behavior and each one becomes a familiar API failure:

• The clickable div with no role is an undocumented endpoint. A <div onClick={...}> styled as a button renders fine and works for mouse users. In the tree it's a generic container with no role and no name. An agent asked to "add to cart" scans the tree for something button-shaped, finds nothing, and either fails the task or clicks something worse.
• The unlabeled form field is a parameter with no name. An input associated with its label only by visual proximity shows up in the tree as textbox: "". The agent filling a checkout form has to guess which blank box is the postal code. Sometimes it guesses wrong, and unlike a human, it confidently submits.
• The empty icon button is a method whose name got stripped. A button whose content is an SVG with no accessible name reads as button: "". Was that close, submit, or delete? The agent finds out the same way a screen-reader user does: by consequence.
• State that lives only in CSS is a response body that never arrives. A custom dropdown that signals open/closed with a class name, without aria-expanded, gives the agent no way to know whether its click worked. It clicks again. Now the menu is closed again.

The scale of this is not hypothetical. WebAIM's annual crawl of the top million home pages keeps finding detectable WCAG failures on roughly 95% of them — about 51 errors per page in the 2025 run, with missing form labels on half of all pages and empty buttons on nearly a third. Every one of those numbers used to represent a degraded experience for a minority of users. Now each is a failure mode for any automated workflow touching your site, at a moment when bot-driven requests have crossed 50% of HTML traffic on some networks.

More ARIA Is Usually the Wrong Fix

The reflexive response — sprinkle ARIA attributes until the audit passes — makes things worse, and the data says so clearly. WebAIM found ARIA usage climbing about 18% year over year to roughly 106 attributes per page, while pages using ARIA averaged twice as many detectable errors as pages without it (57 versus 27). Around a third of ARIA-built menus introduced new barriers: roles without required keyboard interactions, states that never update, labels pointing at IDs that don't exist.

The pattern behind those numbers is retrofit. ARIA gets applied as paint over non-semantic markup, usually by someone who isn't testing against the tree it produces. And a wrong role is worse than no role for an agent, for the same reason wrong API documentation is worse than none: the agent trusts it. Declare role="button" on a div that only responds to mouse events, and the agent's synthesized interaction fails in a way that's much harder to diagnose than a missing element.

The fix that actually works is boring: semantic HTML first. A native <button> gives you role, name computation, focus behavior, and keyboard activation for free — guaranteed consistent across browsers. <nav>, <main>, <label for>, and heading hierarchy carry most of a page's structure without a single ARIA attribute. Reserve ARIA for genuinely custom widgets, and when you use it, implement the full contract — role, states, and keyboard behavior — not just the attribute that satisfies the scanner. This has been the standing advice from accessibility practitioners for fifteen years. The difference is that now the consumers of your semantics include software that files error reports and abandons purchase flows.

Audit the Tree Like You'd Audit an API Contract

If the tree is an API, test it like one. The tooling already exists; it was built for accessibility engineers and works unchanged for agent-readiness.

Open Chrome DevTools, switch on the full accessibility tree view, and look at your critical flows the way an agent will. Better: run Playwright's ARIA snapshot on your checkout, signup, and search pages, and read the YAML it emits. That YAML is, almost byte for byte, the context window your page occupies in someone's agent. Three questions matter for every step of the flow:

1. Can every required action be named? If the tree shows button: "" or a bare generic node where the primary CTA should be, an agent cannot be instructed to click it except by brittle positional guessing.
2. Is every state transition observable in the tree? Loading states, validation errors, expanded menus, items added to cart — if the only evidence is visual, the agent is flying blind between actions. Live regions and ARIA state attributes are how the tree "returns a response."
3. Does the tree tell the truth? Stale aria-expanded values, aria-hidden wrapping content that's actually interactive, labels that no longer match visible text — each is a lie your API tells its consumers, and agents are gullible consumers.

Then make the snapshot a regression artifact. Teams already diff ARIA snapshots in CI to catch visual-refactor regressions; the same diff catches the redesign that silently renamed "Place order" to an unlabeled icon. Research on web agents backs up what you'd expect: task success rates run dramatically higher on pages with clean semantics than on inaccessible ones — one study measured 78% success on fully accessible pages, with steep drop-offs as semantic quality degraded. Your conversion rate for agent-mediated traffic is, to a first approximation, a function of your tree quality.

There's also a strategic layer beyond the tree itself. Cloudflare now scores sites on agent readiness; proposals like the "build the web for agents" line of research argue for explicit machine-readable action specifications alongside human UIs. Those standards will take years to settle. The accessibility tree is the interface that exists today, in every browser, with twenty years of tooling behind it.

The Users Who Were Right All Along

There's a bitter irony worth sitting with. Blind users reported the unlabeled button for years and were deprioritized. An agent integration fails on the same button and it's fixed by Thursday. The incentive flip is real, and it's not flattering.

But take the trade. Every fix that makes your site legible to an agent makes it work better in a screen reader, because it's literally the same tree. The keyboard operability an agent needs is the keyboard operability a motor-impaired user needs. Agent-readiness is the first business case for accessibility that ships with revenue attached, and the beneficiaries include everyone the old business case failed.

The practical takeaway: treat your accessibility tree as a versioned public interface starting now. Snapshot it in CI. Review tree diffs in PRs that touch UI. Put "renders correctly in the accessibility tree" in your definition of done, next to "renders correctly on mobile." The agents are already reading. The only question is whether your site is saying anything they can parse.