The Accessibility Tree: The Browser-Computed Copy of Your Page That AI Agents Read Instead of Pixels

The Page a Browser Computes Is Not the Page You Wrote

The accessibility tree is the semantic model a browser computes from the DOM, then hands to screen readers and AI agents alike, assembled in five stages: mapping, overriding, naming, pruning, then serializing. Digital Strategy Force names that derivation the DSF Computed Semantics Cascade.

That word computed is the whole story. A team authors HTML. A browser then derives a second structure from it, and that second structure is what assistive technology receives. The W3C describes this plainly in Core Accessibility API Mappings, which specifies how user agents expose page content to five separate platform accessibility APIs across Windows, macOS, Linux, then Android.

So the tree is not a copy of your page, it is a lossy derivative of it. Every stage of that derivation can drop something, rename something, or flatten something, and none of those losses produce an error message. The page still renders. The site still looks correct to everyone who checks it the way people check websites, which is by looking at it.

Digital Strategy Force models that derivation as the DSF Computed Semantics Cascade: five ordered stages between the HTML a team ships, then the structure a machine finally receives. The stages run map, override, name, prune, serialize, and each one is a place where meaning is either preserved or quietly lost.

The rule governing the Cascade is the Computed-Not-Authored Principle: what a machine can act on is decided by what the browser computes, never by what the team wrote. A control can carry a perfectly sensible label in the source, then arrive at the agent with a different name, a useless role, or no existence at all. Intent does not survive the Cascade. Only output does.

Agent Readers Split Into Pixel Perception and Tree Perception

There is a widespread claim that AI agents read websites through the accessibility tree. It is true of one population of agents, then flatly untrue of another, and the split runs straight through the vendors whose names an executive would recognise.

The frontier model vendors document a screenshot loop. OpenAI states in its computer use guide that the model looks at the current interface through a screenshot, then returns actions such as clicks, typing, or scrolling, with the developer harness acting as the hands on the keyboard. Google describes the Gemini 2.5 Computer Use loop as taking the user request, a screenshot of the environment, then a history of recent actions, with a fresh screenshot returned after every step. Anthropic's computer use tool is documented the same way, as screenshot capture with mouse then keyboard control.

The frameworks that developers actually wire into production do the opposite. Microsoft states in the official Playwright MCP repository that the server uses Playwright's accessibility tree rather than pixel-based input, with no vision models needed, operating purely on structured data. Google's own Chrome DevTools MCP documents its snapshot tool as producing a text listing of page elements with unique identifiers based on the accessibility tree.

Neither camp is a safe bet to design against alone, because the research shows the two inputs are additive rather than interchangeable. In VisualWebArena, a Carnegie Mellon benchmark of 910 realistic web tasks, an agent given only the accessibility tree completed 7.25 percent of them. Adding image captions took it to 12.75 percent. Adding the screenshot itself took it to 15.05 percent. Every configuration is built on top of the tree, so a broken tree lowers the ceiling for the pixel agents too.

The gap between 15 percent for the best machine configuration then 88.7 percent for a person is the honest state of the art. It is also the reason this matters commercially rather than academically: agents fail most tasks, so anything a site does that raises the failure rate is subtracting from a number that was already fragile. The five stages below are where that subtraction happens, and they sit underneath the broader enterprise agent-readiness audit rather than replacing it.

Stage One, Map: Roles Are Assigned Before Anyone Writes ARIA

The Cascade begins without any developer involvement at all. W3C's HTML Accessibility API Mappings normatively requires user agents to map HTML elements with implicit ARIA role semantics to platform accessibility APIs, element by element. An anchor representing a hyperlink becomes a link. A button element becomes a button. A nav becomes navigation.

The HTML Standard carries the same requirement from the language side, defining accessibility considerations for every element it specifies. This is the stage that works for free, and it is the reason a plain, boringly semantic page is often more agent-legible than an elaborate one.

The consequential mapping is the one nobody notices. A div maps to the generic role, which carries no meaning a machine can act on. A generic node is not an error, it is simply furniture. When a checkout control is assembled from nested divs with click handlers attached in JavaScript, stage one produces a pile of generic furniture where a button should be, then every later stage inherits that emptiness.

This is why the first stage rewards restraint rather than effort. A page built on native elements arrives at stage two already correct, then needs nothing added to stay that way. A page built on generic containers arrives at stage two owing a debt that every subsequent stage has to service, usually with the ARIA that the next section shows is the most common source of new errors.

Stage Two, Override: One Attribute Erases the Semantics Beneath It

Stage two is where a component library quietly deletes the work stage one did for free. An explicit role attribute replaces the implicit role, and the browser complies without complaint. W3C states the position bluntly in its guidance on using ARIA: if a native HTML element or attribute already has the semantics you require, use it instead of repurposing an element then adding a role to make it accessible.

The failure is not exotic, it is the standard output of modern component tooling. A design system ships a styled div, then someone adds a role to make an audit pass, then the role does not match the behaviour the element actually has. The visual result is identical. The computed result is a control the agent classifies wrongly, so it either skips the control or attempts the wrong interaction with it.

There is now population-scale evidence that adding ARIA makes things worse on average rather than better. WebAIM scanned one million home pages in February 2026 then found 133 ARIA attributes per page, a 27 percent increase in a single year. Pages using ARIA averaged 59.1 detected errors. Pages without it averaged 42.

That correlation is not proof that ARIA causes errors, because complex pages attract both. It does dismantle the assumption that more accessibility markup means more machine legibility. Stage two is the one place in the Cascade where doing more work reliably produces a worse result, then it is also the stage most remediation budgets are spent on.

Want to Know What Your Checkout Actually Computes To? Digital Strategy Force reads the computed tree of your revenue pages, so the gap between what was authored then what a machine receives stops being invisible.

Stage Three, Name: Precedence Decides What a Control Is Called

Stage three is the most expensive stage in the Cascade, then it is invisible in every place an executive would think to look. W3C's Accessible Name and Description Computation specifies how a user agent determines the name presented for an element, then it runs as a strict precedence order rather than a merge.

An aria-labelledby reference outranks an aria-label. An aria-label outranks the native label or alt text. Those outrank a title attribute. The visible text of a control sits near the bottom of that order, which produces the defect this article exists to name: a button that plainly reads Add to Cart on screen can compute to something else entirely, because a stale aria-label written months earlier outranks the words a customer can see.

An element the browser cannot name is an element the agent cannot choose.— DSF Web Development Division

This is also where compliance testing gives false comfort. WCAG 2.2 Success Criterion 4.1.2 requires that name then role can be programmatically determined for every user interface component. A control with a wrong name passes that criterion, because a name exists. It is only wrong, and wrong is indistinguishable from correct to an automated scanner.

The practical consequence is that the name an agent uses to find your most valuable control is set by whichever attribute happens to rank highest, not by editorial intent. Four teams can touch a checkout button over two years without any of them realising which one owns its computed name.

The last row is not hypothetical. WebAIM detected empty buttons on 30.6 percent of the million home pages it scanned, then empty links on 46.3 percent, then missing form labels on 51 percent. Roughly half the commercial web ships controls that compute to nothing, which is the difference between a site an agent can transact on then a site it abandons.

Stage Four, Prune: Rendered and Readable Are Different Sets

Stage four is where the tree stops resembling the page. WAI-ARIA 1.2 specifies that elements are excluded from the accessibility tree, including their descendant elements, when host language semantics say the element is not displayed. Chrome documents the tree as a derivative of the DOM simplified to remove nodes that carry no semantic weight.

Pruning is correct behaviour, then it is also the least intuitive stage for anyone who has not read the specification. The phrase that matters is including their descendant elements. Hiding one wrapper removes everything inside it. A single aria-hidden on a container can delete an entire product grid from the machine-readable page while leaving it perfectly visible to customers.

This is the stage that breaks the mental model most teams operate on, which is that testing means looking. Nothing on the rendered page indicates that a subtree has been excluded. The layout is intact, the copy is present, then the machine-readable version of that region is simply absent, and the only way to detect it is to read the computed tree rather than the screen.

Pruning also explains a pattern that looks inexplicable from the outside: an agent that handles a competitor's checkout confidently, then stalls on yours, despite both pages looking equally professional. The competitor is not better designed. Their tree simply still contains the controls.

Stage Five, Serialize: Tree Size Becomes a Spending Limit

An agent does not walk a live tree. It receives a flattened text rendering of one, which Chrome DevTools MCP documents as a snapshot listing page elements with unique identifiers derived from the accessibility tree. That snapshot has to fit inside a context window alongside the task, the history, then everything else the model is holding.

This converts page structure into a budget. Researchers at NEC Corporation measured the same benchmark pages both ways then found the accessibility tree averaged 6,720 tokens against 56,653 tokens for raw HTML, roughly eight times smaller. That compression is exactly why frameworks prefer the tree.

The same research carries a finding that complicates the enthusiasm, then deserves stating plainly because it cuts against the simple version of this story. On one benchmark, agents given raw HTML outperformed the same agents given the accessibility tree: 67.0 percent against 52.4 percent for one model, then 73.3 percent against 55.8 percent for another. The tree is cheaper, and it is also lossier.

That loss is not an argument against the tree, it is the argument of this article. The gap between the two representations is precisely the meaning the Cascade dropped during mapping, overriding, naming, then pruning. A site whose tree survives those four stages intact loses far less in the compression, because there was nothing left to lose.

Page weight then compounds the problem. WebAIM measured 1,437 elements on the average home page in February 2026, a 22.5 percent increase in a single year. Every generic wrapper that survives into the snapshot spends budget that a purchase control needed, which is how a bloated component tree quietly crowds a company's own conversion path out of the window an agent can afford to read.

Two Separate Mandates Land on the Same Computed Artifact

The commercial case does not rest on agent traffic alone, which matters because agent traffic is still a forecast rather than a receipt for most companies. The same computed artifact is already regulated, so two independent obligations now converge on one piece of work.

The regulatory side is settled law in two jurisdictions. The European Accessibility Act required member states to apply its measures from 28 June 2025, and it names e-commerce services delivered through websites as in scope. In the United States, the Department of Justice holds that ADA requirements apply to the goods then services offered by public accommodations, including those offered on the web.

Meanwhile the readiness baseline is poor almost everywhere. WebAIM found detected WCAG failures on 95.9 percent of one million home pages in February 2026, worse than the 94.8 percent recorded a year earlier, at an average of 56.1 errors per page.

The traffic side is moving faster than the compliance side. Cloudflare reported in July 2026 that more than half of internet traffic is now non-human, then that 52 percent of crawler requests are for AI training as of June 2026, up from 22 percent in spring 2025. Those are network-level observations from one provider rather than an audited study, so treat them as direction rather than precision.

What makes this unusual as a business case is that the two mandates share a work item. Fixing the computed tree satisfies a legal obligation that already exists, then it improves machine legibility for a channel that is still growing. Most infrastructure spending has to choose between defending against a risk then investing in an opportunity. This one does both with the same budget line, which is the strongest argument for doing it deliberately rather than waiting for a complaint.

The Computed Tree Is Inspectable, So None of This Is Guesswork

Everything above is verifiable on a company's own site in an afternoon, which is what separates the Cascade from an audit opinion. Chrome ships a full accessibility tree view in its developer tools, so the structure an agent receives can be read directly rather than inferred.

The Chromium project documents that accessibility support is enabled on demand rather than running always, which means the machinery producing the tree for an assistive technology user is the same machinery a team can switch on to read it. That also makes this a different exercise from publishing parallel machine channels such as schema or feeds, because the tree already exists whether anyone maintains it or not. There is no separate agent view to reverse engineer. There is one computed artifact, then several consumers of it.

Run those five checks against a checkout, a pricing page, then a contact form, and the result is not an opinion about readiness. It is a list of specific nodes that either survived the Cascade or did not, with a named stage attached to each failure, which is what makes the work estimable rather than open ended.

The reason to do this now is not that agents are about to become the majority of buyers. It is that the accessibility tree is the only representation of a website that is simultaneously required by law in two major markets, consumed by every assistive technology user, then used as the primary observation format by the agent frameworks being embedded into software today. Three constituencies, one artifact, one budget line.

The uncomfortable part is that none of it is visible from the place most companies look. A site can pass a design review, satisfy an automated scanner, convert well for human visitors, then still hand a machine a structure in which the most valuable control on the page has no name. The tree is computed whether anyone reads it or not. The only real choice is whether the company reading it first is yours.

FAQ — Accessibility Tree

Next Steps — Accessibility Tree

• ▶ Open the full accessibility tree on your checkout, then read the computed name of the primary action out loud.
• ▶ List every control on a revenue page whose computed name differs from its visible label, since those are unmatchable.
• ▶ Audit your component library for explicit roles applied to native elements that already carried the right semantics.
• ▶ Search the codebase for aria-hidden on wrappers, because the exclusion reaches every descendant beneath it.
• ▶ Fund the fix once against both mandates, since the same work answers a legal obligation then an agent-legibility gap.

Digital Strategy Force reads the computed tree of your revenue pages stage by stage, so the losses have names before they cost anything. Talk to the web development team.