Accessibility-Tree Locators: Resilient Playwright Tests with AI (2026)

Give an AI a dump of raw DOM HTML and ask for a Playwright locator, and it will hand you div.MuiBox-root > button.css-1x9f7z8. That selector is dead on arrival - it breaks the first time someone renames a class or a build tool re-hashes a style module. Give the same model the accessibility tree instead, and it writes getByRole('button', { name: 'Submit' }), which keeps working across refactors that would shatter the CSS version. This is not a prompting trick. The accessibility tree is a fundamentally better input: smaller, more stable, and closer to user intent. This post explains why, how Playwright MCP exposes it to agents, and shows a before-and-after.

This companions our pillar, Building a Self-Operating QA Agent with Playwright MCP, and pairs naturally with Playwright MCP vs Playwright CLI for AI Agents.

What is the accessibility tree?

The accessibility tree is the browser’s semantic model of a page - the same one screen readers and other assistive technology consume. Where the DOM is a full structural description of every node, wrapper, and styling hook, the accessibility tree keeps only what matters for meaning: each element’s role (button, link, textbox, heading), its accessible name (the label a user perceives), and its state (checked, disabled, expanded).

That distinction is the whole story. A page might wrap a button in five nested divs with hashed class names for layout; the accessibility tree collapses all of that to one line - button "Submit". The structure churns constantly across releases; the role and name rarely do.

Why are role-based locators more resilient?

A locator is a bet on what will stay stable. CSS and XPath bet on structure: class names, tag hierarchy, element position. Structure is exactly what developers change most - they rename classes, add wrappers, reorder nodes, swap a div for a section. Every one of those edits can break a structural selector while the feature works perfectly.

Role-based locators bet on intent: what the element is to a user. getByRole('button', { name: 'Submit' }) does not care how many divs wrap the button or what its class is called. It keeps matching as long as the element still presents as a button named Submit - which is to say, as long as the feature still exists. Playwright’s getByRole, getByLabel, and getByText all query this tree, which is why the Playwright team recommends them as the default, user-facing locators.

There is a bonus: if you cannot reach an element by role or label, that usually means it has no accessible name, which is a real accessibility defect. Writing accessibility-first locators surfaces those gaps instead of papering over them with a data-testid.

Why does the accessibility tree help AI specifically?

Two reasons, and they compound.

It is more token-efficient. Raw HTML for a single view can run to tens of thousands of tokens of nested markup, inline styles, and framework noise. The accessibility snapshot of the same page is a compact list of roles and names - a fraction of the size. For an AI agent working within a context budget, that means more of the page fits at once, and less of the budget is spent parsing markup irrelevant to finding elements. We go deeper on this in Token-Efficient AI Testing in CI/CD.

It steers the model toward resilient output. An LLM copies patterns from its input. Feed it raw HTML full of class names and it copies those classes into CSS selectors. Feed it a tree of roles and names and it naturally reaches for getByRole and getByLabel, because that is what the input describes. The input shapes the output. Smaller input, more resilient output - the two benefits are the same mechanism seen from two angles.

How does Playwright MCP expose ARIA snapshots?

Playwright MCP is the bridge between an AI agent and a live browser, and its defining design choice is what it feeds the model. Instead of returning a screenshot or a wall of HTML, its browser_snapshot tool returns a structured ARIA accessibility snapshot of the current page - the roles, names, and states, laid out for a model to read.

The consequence is direct: an agent driving the browser through MCP sees the page as an accessibility tree, so when it generates or executes interactions it uses role-based locators by default. That is a large part of why MCP-driven agents produce more resilient tests than agents handed a raw DOM dump. The tool shapes the behavior. For the fuller comparison of MCP versus the CLI, see Playwright MCP vs Playwright CLI for AI Agents.

Playwright also exposes ARIA snapshots in test code directly, so you can assert on the tree, not just locate through it:

await expect(page.locator('body')).toMatchAriaSnapshot(`
  - heading "Checkout" [level=1]
  - textbox "Full name"
  - textbox "Card number"
  - button "Place order"
`);

That assertion passes as long as the page presents those roles and names, and it reads like documentation of the page’s semantics.

Before and after: a fragile selector vs getByRole

Here is the pattern in practice. First, what an AI writes when fed raw DOM HTML - structural, hashed, and doomed.

// Fragile: bound to structure and generated class names.
await page.locator('div.MuiBox-root > form > button.css-1x9f7z8').click();
await page.locator('#root > div:nth-child(2) input[name="email"]').fill('[email protected]');
await expect(page.locator('div.toast.toast--success')).toBeVisible();

Every line here is one refactor away from breaking. A theme change re-hashes css-1x9f7z8. A layout tweak adds a wrapper and breaks the nth-child(2) path. None of it reflects what the user actually does.

Now the same interactions written from the accessibility tree - what an MCP-driven agent produces.

// Resilient: bound to role and accessible name.
await page.getByRole('button', { name: 'Place order' }).click();
await page.getByLabel('Email').fill('[email protected]');
await expect(page.getByRole('status')).toContainText('Order confirmed');

This survives class renames, added wrappers, and reordered nodes, because none of those change the fact that there is a button named “Place order,” an input labeled “Email,” and a status region confirming the order. It is also far easier to read - anyone can see what it tests without opening the app.

When should you still reach for CSS or test IDs?

Accessibility-first does not mean accessibility-only. Some elements genuinely have no role or accessible name - a decorative container, a canvas, a chart region, a bare wrapper you need to scope within. For those, a data-testid is the honest fallback:

await expect(page.getByTestId('revenue-chart')).toBeVisible();

The priority order in 2026: getByRole, getByLabel, and getByText first; getByTestId when there is no meaningful role; raw CSS only as a last resort. And when you find yourself needing a test ID because an interactive element has no accessible name, treat that as a bug ticket, not just a locator workaround. The fix helps your users and your tests at the same time.

Where does this fit in a 2026 SDET workflow?

Resilient locators are the foundation everything else in an AI testing stack sits on. Generated tests, self-healing fixtures, exploratory agents - all of them are only as durable as the locators they produce, and locators are only as good as the view of the page the model was given. Feed agents the accessibility tree through Playwright MCP and you get resilience and token efficiency for free, plus an accessibility signal you would otherwise have paid a separate audit for.

Start with the pillar guide to see where locators sit in the wider agent workflow, and pair this with Dynamic Self-Healing Locators with Playwright Fixtures for what to do when even a role-based locator needs to adapt. Bet on intent, not structure, and let the accessibility tree do the work.