A site can be easy to find and difficult to use. For an AI agent sent to choose a product, request a quote, or book an appointment, that difference determines whether discovery turns into an outcome.
Start with the interface you already have. Missing labels, misleading control names, and unclear completion states can break agent journeys. The studies reviewed here give reasons to investigate those defects, though they do not establish a formula for predicting agent success from an accessibility score.
One button, two conflicting instructions
MERJ tested a document editor whose visible Save and Cancel buttons had deliberately misleading ARIA labels. In its March 2026 test, ChatGPT Agent clicked Cancel first in all 25 runs. Claude Computer Use and Perplexity's Comet agent selected Save in all 25. Different ways of reading the same interface produced different actions. [1]
MERJ also reports average success rising from roughly 30% to 60% across its test suite during the research period. The result applies to its selected scenarios and tested configurations. It cannot establish how often today's agents complete ordinary web tasks. MERJ sells agent monitoring; its examples are useful diagnostic evidence from a commercial researcher. [1]
For your own budget, the question is narrower: does a specific defect interrupt an important task on your site?
How accessibility information reaches an agent
Microsoft's Playwright MCP documentation describes browser interaction through structured accessibility snapshots. This is one concrete implementation that uses accessibility information. Commercial browser agents can use different representations. [2]
W3C's Name, Role, Value criterion addresses programmatically available control names, roles, states, and values. Correctly implemented native controls simplify this work. A custom selector needs to communicate what it is, what is selected, and what changes when someone uses it. [3]
A related criterion, Label in Name, requires a control's accessible name to contain its visible text label where such a label exists. A button that displays “Request a quote” but exposes a different action in its accessible name creates an avoidable conflict. [4]
An agent that relies on those representations can make the wrong decision when the interface supplies inaccurate information. This is an inference from the mechanism described above. That mechanism gives you a reason to test the component. It does not establish accessibility as the strongest predictor of agent performance.
Common defects, unmeasured agent impact
WebAIM's February 2026 analysis of one million home pages found missing form labels on 51% of pages, empty links on 46.3%, and empty buttons on 30.6%. Each percentage describes home pages with detected issues. It does not describe the share of individual controls or agent journeys affected. [5]
The study analyzed rendered pages with WAVE. Automated checks cover part of accessibility, so a clean result cannot establish full conformance. Home pages also cannot describe the condition of every checkout, account screen, or booking form behind them. [5]
Multiplying those prevalence figures by an agent benchmark would not produce a valid lost-conversion estimate: the studies use different populations and outcomes. None of the sources reviewed for this article quantifies what share of all browser-agent failures is caused by accessibility defects.
Audit a journey, then test the repair
Select one valuable journey that can be exercised without a real purchase or message: locating a suitable product, preparing a booking in a test environment, or completing a demonstration quote form. Use it for a small diagnostic experiment.
- Define success before the run. Write down the required state: selected service, correct product variant, saved form, or confirmed test booking. Verify that state even if the agent says it finished.
- Keep the conditions comparable. Record the agent, model when exposed, browser, language, login state, starting URL, prompt, and date. Reset the session between trials. Keep the same settings for the before-and-after comparison.
- Capture the first consequential error. Save the relevant screenshot, control name, action, and resulting state. Distinguish selecting the wrong control from a network failure, an access restriction, or a mistaken plan.
- Repair a specific interface defect. Change the label, role, state exposure, or feedback implicated by the trace. Avoid redesigning the entire journey during the same comparison.
- Repeat and inspect. Report completed tasks out of attempted tasks, together with retries and time. A small pilot can reveal repeatable failures; it cannot establish a market-wide success rate.
This is a proposed testing approach. GEOClarity has not run a controlled study of these repairs. Keep the original traces so a later model update can be distinguished from a site improvement.
A short repair checklist
- Name the action. Give buttons and links an understandable purpose; check that visible wording and accessible names agree.
- Expose the current state. Inspect selected options, expanded panels, disabled controls, and validation states as well as their visual appearance.
- Make completion observable. Show a clear result after a save or submission. Where a status message does not receive focus, expose it programmatically as W3C's Status Messages guidance describes. [6]
- Test recovery. Use an invalid field value or unavailable option and check whether the next step is understandable.
- Verify the result. Where possible, check the actual saved record or test-system state alongside the success banner.
Keep human accessibility evaluation in the process. An agent completing a task does not demonstrate that a disabled person can complete it. An accessibility audit also cannot measure every agent's planning or recovery ability.