Agents read the accessibility tree.

On 24 September AudioEye published a study that should end an argument we have had with clients for years. It sent AI agents from six commercial models to complete 13 everyday tasks across six websites, ten times each, 1,560 runs in total. The same tasks were run with and without accessibility fixes in place. On the site with the most accessibility problems, agents completed 31% of what they were asked to do. On an accessible version of that same site, they completed 96%.

Every model dropped by roughly two thirds on the inaccessible version, including the most capable ones. This is not a weak model struggling. It is a strong model being handed a broken map.

What the agent actually reads

The reason is mechanical. Many agents do not look at a page the way a person does. They read the accessibility tree, the structured description of the page the browser builds for assistive technology: this is a button, it is called Add to basket, this is a form field, it expects a postcode. When a button has no name, a field has no label, or a price only exists inside an image, the tree has a hole in it, and the agent falls through.

AudioEye's sharpest example is the one we would pin to the wall. One task needed figures that appeared only inside an image with no text alternative. All 60 attempts, six models across ten runs, failed. No amount of model capability recovers data that was never published in a form software can read.

"

An unlabelled button was always a bug for a screen reader user. Now it is also a bug for every assistant a customer sends to your site on their behalf.

It also costs more to fail

The study found agents used a median of 43% more tokens on the inaccessible sites, 128,000 against 90,000, and up to six times more at the extreme. An agent that cannot find the control keeps looking. Somebody pays for that search, and increasingly it will be the business whose site forced it.

The timing matters. At Amazon Accelerate on 23 September, Amazon opened its seller tools to outside AI agents, starting with a beta plugin for Claude that can manage listings, prices and inventory with the seller's approval. The day after, NielsenIQ reported that 51% of US consumers had used an AI tool to help them shop in the past month, the first time that figure has crossed half. Agents are arriving on both sides of the counter, and the interface they share is the one we have been told to treat as compliance.

What we would do on our own builds

• 01Treat the accessibility tree as a public interface. Review it the way you would review an API response: every control named, every field labelled, every state exposed.
• 02Use native elements. A real button, a real select and a real form get correct roles for free. A div with a click handler gets nothing, for people or for agents.
• 03Never put data only in pixels. Prices, opening hours, stock levels and figures in a chart need a text equivalent, or they do not exist to software.
• 04Keep the path to purchase or booking short and predictable. Agents, like people, fail most on multi-step flows that change shape as you go.
• 05Add an agent run to the test suite. A scripted agent attempting the three tasks that matter most on the site, on every release, catches regressions a visual review never will.

Where we would be careful

AudioEye sells accessibility tooling, so read the framing with that in mind, although the method was validated with an independent judging system from Ohio State University. And an overlay or widget that patches the tree after the page loads is not the same as a page built correctly. The fix is in the markup, done once, at source.

The case for accessible software never needed a commercial argument. It now has one anyway. Build for the person using a screen reader and you have also built for the assistant booking a table, comparing prices or reordering stock. It is the same work, and it has become the cheapest way to make a site usable by the software that is starting to use it.