Accessibility tree web testing: how AI test agents drive browsers without CSS selectors

Why the accessibility tree, why now

For two decades, the standard way to address an element in a browser test was a CSS selector or an XPath expression. That worked when markup was hand-written, components were stable, and a button stayed a button for a year at a time. It does not work in a 2026 codebase where the same button is implemented by three different design system versions across the app, where Tailwind class strings change every sprint, and where an LLM rewrites a wrapper div without anyone noticing.

The accessibility tree is different. It is the structure the browser exposes to assistive technology. Every node has a stable identity built from three things: a role (button, textbox, link, heading, dialog), an accessible name (the text a screen reader would announce), and a small set of states (disabled, checked, expanded, selected). None of those are coupled to your CSS, your component library, or how you write your JSX. They are coupled to what the element is, semantically.

Tests that address elements by role and name behave like users do. When a designer rewrites the button as a styled div without restoring the role, the test fails. So does the experience for anyone using a screen reader. That is a useful coincidence: the test is now a continuous accessibility check, paid for by the QA budget instead of fought for separately.

What changes in the test code

// Brittle: dies on any class rename
await page.click('.btn.btn-primary.signin');

// Even worse: positional
await page.click('form > div:nth-child(3) > button');

// Test-id: works, requires team buy-in
await page.click('[data-testid="signin-button"]');

The flaky test you have written before

Toggle between the two versions. The behavior is identical. Only the selector strategy changed.

How an AI test agent actually consumes the tree

A hand-written Playwright test calls getByRole('button', { name: 'Sign in' }) and the framework walks the accessibility tree for you. An AI agent driving the browser does not get that affordance for free. It needs to seethe tree, decide what to act on, and use a stable reference back to the framework. Here is the loop, taken from Assrt's open source agent at src/core/agent.ts.

The anchor fact: a 120,000 character ceiling

One detail you will not find in the marketing pages of any other AI test tool: there is a hard cap on snapshot size. In Assrt's source it is set in src/core/browser.ts:

/** Max characters for a snapshot before truncation
 *  (roughly ~30k tokens). */
private static readonly SNAPSHOT_MAX_CHARS = 120_000;

The reason is grim and obvious: a Wikipedia article, a sprawling admin dashboard, an infinite scroll feed, all produce accessibility trees that would blow past any agent's context window the moment you serialized them. The cap forces an honest conversation about scope. Tests that try to operate on entire pages are usually testing the wrong thing. Tests that target a section, a dialog, or a flow rarely come close to the limit.

When the cap is hit, the snapshot is truncated at the last clean line break and a marker is appended so the agent knows the view was partial. The behavior lives in the resolveAndTruncate method right above the constant. If you are building your own agentic test runner, copy this pattern. It is the difference between a test that runs and a test that exhausts your token budget mid-flow.

What a snapshot actually contains

What it does not contain: CSS classes, inline styles, image pixel data, JavaScript event handlers, or any markup that exists purely for layout. That omission is the point. If something is not in the accessibility tree, your tests cannot target it, and your users with assistive tech cannot use it either. Both gaps are the same gap.

Accessibility tree testing vs the alternatives

When the accessibility tree is the wrong tool

It is not a universal answer. There are real cases where you want to target the DOM directly. Canvas-rendered apps (large data visualizations, in-browser CAD, some game engines) have no accessibility tree to speak of, just a single canvas node. Tests for those have to fall back to coordinate clicks or hidden DOM mirrors. Visual regression tests measure pixels, not roles, and should not pretend otherwise. And anything that depends on a specific CSS property (a hover color, a transition timing, a print layout) needs to look at styles, not the tree.

The honest position is: use the accessibility tree as the default target for behavioral tests, and reach for CSS or visual diffs only when the thing you are checking is not behavior.

Try the loop on your own app

Assrt is open source and runs as a Node CLI. You point it at a URL, it crawls the accessibility tree, generates scenarios, and writes real Playwright spec files into your repo. The tests are yours, not a rented YAML format you have to escape from later.

npx @m13v/assrt discover https://your-app.com

Read the generated spec before you commit it. If a scenario is junk, delete it. If it is good, treat it like any other Playwright test in your suite: run it in CI, fix it when product behavior changes, retire it when the feature is gone. The accessibility tree is the substrate; the tests are still yours to own.

Frequently asked questions