For twenty years the argument for semantic HTML was about people: screen reader users, keyboard users, people using voice control. That argument has not changed. What has changed in 2026 is that a second, very large audience reads the web the same way, and it is not human. Browser agents that shop, book and fill in forms on a user’s behalf navigate pages through the accessibility tree, the same structure of roles, names and states that assistive technology uses. Sites that break it for people break it for agents too.

How agents read a page

Agents have three ways to perceive a page: the DOM, screenshots, or the accessibility tree the browser derives from the DOM. The tree is cheaper in tokens than an image and states outright what each element is and what it is called, so it is the preferred input where it works. Microsoft’s Playwright MCP server, widely used to give models a browser, states that it uses the accessibility tree rather than pixel-based input. OpenAI’s publisher FAQ for its Atlas browser says the browser uses ARIA tags, the same labels and roles that support screen readers. Its earlier Operator agent worked mainly from screenshots, and hybrid approaches combine the tree with vision for canvas-rendered interfaces the tree cannot describe.

Google has gone further and built it into tooling. Earlier this year Lighthouse gained an Agentic Browsing category. Its scoring documentation says agents rely on the accessibility tree as their primary data model and describes the tree as a core metric for agentic navigation. The audits it runs are a subset of the accessibility audits: interactive elements have programmatic names, roles and parent-child relationships are valid, and interactive content is exposed to the tree. It also measures layout shift, because an element that moves between being identified and being clicked defeats an agent, and checks for an llms.txt file. The category is informational for now and not yet benchmarked.

The scale is not small. Cloudflare Radar measured 57.2 per cent of HTML requests in the week to 5 June 2026 as coming from bots, as Search Engine Journal reported in a good explainer of the tree.

What breaks the tree

The list is familiar because it is the WebAIM Million list (see our summary):

  • Empty links and buttons produce nodes with a role but no name. An agent cannot tell “Add to basket” from “Remove”.
  • Unlabelled inputs cannot be mapped to a purpose, so they cannot be filled.
  • Clickable divs become nameless, roleless nodes that neither a screen reader nor an agent can trust.
  • Missing alt text contributes nothing to the tree.
  • Over-used ARIA gives confident but wrong information. WebAIM found pages with ARIA averaged 59.1 errors against 42 without.
  • Canvas rendering and client-only content leave the tree empty where the key information is.

The AI-generated code problem

There is an irony here. In a July 2026 post, Deque’s chief executive Preety Kumar collected several data points on the code that AI assistants produce. In Deque’s survey of 200 engineering leaders, 88 per cent said they trust their AI-generated code to be accessible. Yet in Microsoft’s evaluation framework six of ten models failed every automated accessibility test, and in the GAAD Foundation’s AIMAC benchmark 35 of 37 leading models produced multiple critical or serious issues by default. Models generate markup that looks right and exposes nothing, and the agents built by the same industry then struggle to use it.

What to do

  1. Native elements first. A button is a button element, a link has an href, a select is a select. This is the W3C’s first rule of ARIA and it is what agents parse best.
  2. Name everything. Every link, button and input has a visible label or an accessible name, including icon-only controls.
  3. Render the facts in HTML. Prices, availability, specifications and the primary action should be server-rendered text, not images or canvas.
  4. Use ARIA for gaps, not decoration. Check that every aria-hidden and role attribute earns its place.
  5. Look at the tree. Browser developer tools show the accessibility tree directly. Confirm each important action has a clear role and name. The same applies to native apps: VoiceOver and the natural-language Voice Control Apple has announced for iOS 27 both resolve to the app’s accessibility elements.
  6. Review generated code as code. Put an automated accessibility check in the pipeline and treat its failures as build failures, whoever or whatever wrote the markup.

None of this changes the reason to do it. People come first, and the law is written for people. But if you have struggled to get accessibility work prioritised, the fact that the same work decides whether your site works in an agent-mediated purchase is an argument that lands with people who did not listen before.

Try it this week

Audit your most important page in Accessibility Checker. Every empty link, empty button and unlabelled field it reports is a node an agent cannot use either. Then read WCAG: Robust, the principle about exposing name, role and value.

Back to Blog