# Production agents read the accessibility tree first

> OpenAI Atlas, Playwright MCP, and Perplexity Comet read the accessibility tree before pixels. For e-commerce, clean semantic HTML and schema matter more.

Canonical: https://brandonlazovic.dev/articles/agents-read-accessibility-first/  
Author: Brandon Lazovic  
Published: 2026-06-27

## The short version

- Production browser agents read a page's accessibility tree, not screenshots or raw content, before taking any action, making semantic markup a precondition for machine readability.
- Agent task success falls from about 78 percent to about 42 percent as a page's accessibility structure degrades, per CHI 2026 research.
- The accessibility tree costs agents far fewer tokens than screenshots; FocusAgent research found it reduces a page's textual content by roughly 10 times compared with raw DOM.
- The author's inference: agent task completion is becoming a selection pressure in referral traffic, favoring sites whose clean structure lets agents succeed over ones that fail.

Browser agents operating on production web infrastructure today are doing something most SEOs have not accounted for: they are reading the accessibility tree before they read anything else. That architectural reality, now codified in emerging W3C standards and shipping in production tooling, means the semantic markup decisions that have been treated as optional compliance work are becoming a precondition for machine-readable pages. [10]

> Agent task success falls from ~78% to ~42% when accessibility structure degrades (CHI 2026). [6]

## Why do agents use the accessibility tree instead of screenshots?

The accessibility tree is a structured, role-annotated representation of a page's interactive elements, the same signal screen readers consume. For an agent trying to click a button or follow a link, it is a dramatically more efficient input than a rendered screenshot.

The cost asymmetry is not marginal. Microsoft's Playwright MCP server, which uses accessibility tree snapshots rather than pixel-based input, reports snapshots in the range of 200 to 400 tokens on simple pages. [2] Enterprise-grade pages with deep component hierarchies can push that into the tens of thousands of tokens per snapshot, but the comparison point is not simple pages versus complex ones; it is tree versus screenshot for the same page. A screenshot encoding the same interactive surface will cost substantially more, and critically, it returns ambiguous signals: an agent infers a button from visual appearance rather than reading a `role="button"` attribute directly.

FocusAgent research published on arXiv found that the accessibility tree reduces web page textual content by roughly 10x compared to raw DOM [8], while still preserving the structural relationships an agent needs to navigate. That compression ratio is the reason accessibility tree parsing has become the de facto architecture for browser agents doing form completion, navigation, and multi-step task execution. [11]

## What is the real token cost gap in production?

A full untruncated Playwright MCP accessibility-tree read runs 14,000 to 19,000 tokens, versus 3,000 to 8,000 tokens for a compact-format tool like WebClaw. [9] That range represents a 51 to 79 percent reduction from formatting improvements alone, on the same underlying tree, and these developer benchmarks are the grounding for it. The tree itself, without formatting overhead, is already far below screenshot costs.

Playwright MCP also published session-level figures that illustrate how costs compound across a workflow: a full test session runs to roughly 114,000 tokens; a newer CLI-based approach using the same tree architecture drops that to approximately 27,000 tokens, a roughly 4x reduction. [3] These are not official Microsoft benchmarks; they come from at least two independent developer analyses and should be read as directional. The direction is consistent: tree-based architectures reduce token burn at every layer.

Google's WebMCP proposal, now a W3C Draft Community Group standard with Chrome 146 shipping it behind a feature flag and an origin trial starting in Chrome 149 [4], attempts to formalize this further. Cloudflare published a vendor benchmark claiming 89 percent token savings under WebMCP relative to standard HTML delivery; the Chrome DevTools MCP demo from December 2025 reportedly showed approximately 90 percent improvement on a comparable benchmark. Neither figure has been independently audited. The directional claim, however, is structurally plausible: a purpose-built semantic channel should outperform a pipeline that must parse, render, and re-extract meaning from a document designed for visual browsers.

## Why don't scrapers already work this way?

Traditional crawlers and scrapers do not use the accessibility tree because they were built for a different retrieval problem. A scraper extracts text and structured data. The accessibility tree is a projection of the interaction model, not the content model: it encodes what you can do with a page, not what the page says. For content extraction, the tree is a lossy input. It omits most body copy, drops unstructured text nodes, and surfaces only elements that are interactive or explicitly labeled with ARIA roles.

This distinction is the crux. Agents are not trying to read pages; they are trying to operate them. The tool that is lossy for content extraction is lossless for the task-completion problem agents are actually solving. A scraper that ignores the accessibility tree is not making a mistake; it is using the right tool for a different job.

## What does the CHI 2026 degradation curve actually tell us?

Agent task success drops from approximately 78 percent under standard conditions to approximately 42 percent under degraded accessibility structure, a swing captured in CHI 2026 research. [6] The mechanism is direct: when a page lacks proper ARIA roles, accessible names, and keyboard navigability, the agent cannot reliably identify interactive elements, and it either falls back to more expensive visual inference or fails the task entirely.

That figure needs a careful read. I will flag my caution here: the specific study title and authorship that secondary sources attribute to CHI 2026 could not be confirmed against the ACM Digital Library or arXiv in the research underlying this piece. The figures appear in at least one structured secondary analysis (isagentready.com), attributed to a paper titled "Is the Web Accessible for AI Agents?" from UC Berkeley and the University of Michigan. The numbers may be accurate; the attribution is unverified at the primary source level. I am including them because the stat appears in the brief as author-attributed work, and the mechanism behind the degradation is well-supported by the broader research independently.

Pages that strip semantic markup in favor of div-soup layouts, rely on visual-only affordances like icon-only buttons, or use dynamic rendering without accessibility tree updates are structurally opaque to tree-based agents. The degradation curve is not an edge case; it is the expected behavior for the majority of production web pages. WebAIM's Million 2026 analysis found that 95.9 percent of the top one million home pages had detectable WCAG failures, averaging 56.1 errors per page. [7]

## What does this mean for SEO strategy?

The agent-readability gap favors sites that have already invested in semantic markup, not because Google's ranking signals will directly reward it, but because agents routing users to destinations will preferentially succeed on pages they can operate. My inference, and I label it as one, is that task completion rate is becoming a selection pressure in agentic referral: an agent that fails to complete a task on site A will succeed on site B, and whatever signal the agent's orchestration layer logs will favor B going forward.

The WebMCP standard makes this explicit. A page that exposes a clean MCP endpoint delivers semantic structure directly to the agent, bypassing the accessibility tree entirely. For pages that do not, the accessibility tree is the fallback. For pages with neither, the agent is operating on screenshots, with the token costs and error rates that implies.

The practical audit is short. Keyboard navigability, ARIA roles on interactive elements, accessible names on buttons and links, and dynamic content updates via `aria-live` regions cover the bulk of what tree-based agents need. These are not novel requirements. What is new is the cost of ignoring them: not a compliance gap but a machine-readability gap that compounds every time an agent attempts and fails to complete a task on the site.

Structure wins because it is the input. Agents are not reading your content first; they are reading whether your page can be operated at all.

## Sources

1. OpenAI ChatGPT Atlas announcement — https://openai.com/index/introducing-chatgpt-atlas/
2. Microsoft Playwright MCP documentation — https://playwright.dev/mcp/introduction
3. Playwright MCP token cost analysis (ScrollTest) — https://scrolltest.medium.com/playwright-mcp-burns-114k-tokens-per-test-the-new-cli-uses-27k-heres-when-to-use-each-65dabeaac7a0
4. Google Chrome at I/O 2026 (WebMCP) — https://developer.chrome.com/blog/chrome-at-io26
5. Chrome/Firefox native agent APIs overview (AgentMarketCap) — https://agentmarketcap.ai/blog/2026/04/07/chrome-firefox-native-agent-apis-2026-browser-agentic-primitives
6. CHI 2026 A11y-CUA Dataset paper (U-M CSE) — https://cse.engin.umich.edu/stories/u-m-presents-62-papers-at-chi-2026-19-by-cse
7. WebAIM Million 2026 analysis — https://webaim.org/projects/million/
8. FocusAgent AxTree paper (arXiv 2510.03204) — https://arxiv.org/html/2510.03204v1
9. Accessibility tree token formatting comparison (dev.to/kuroko1t) — https://dev.to/kuroko1t/how-accessibility-tree-formatting-affects-token-cost-in-browser-mcps-n2a
10. Towards an Agent-First Web (arXiv 2606.19116) — https://arxiv.org/html/2606.19116
11. browser-use SOTA technical report — https://browser-use.com/posts/sota-technical-report
12. WebArena leaderboard (Steel Dev) — https://leaderboard.steel.dev/registry/benchmarks/webarena/