Post 1 of 5 in our series on AI-assisted code and accessibility.
Agentic coding is an overwhelming trend. Development teams across the globe are racing to understand how to fit AI assistance into the way they ship features and components. And for good reason: many studies show agentic coding can raise productivity up to 50%. That’s an amazing story.
When it comes to accessibility, however, that’s another story altogether. And while there is a long list of research results to tell that story, we decided to run an experiment of our own.
A simple experiment
The setup was simple.
We had three popular AI models (Claude 4.5 Sonnet, GPT 5.1, and Gemini 2.5 Pro) each build the same app, a board game catalog, three different ways:
- React with Bootstrap
- Svelte with Tailwind
- plain JavaScript
We gave no instructions about accessibility, because that is how most AI-assisted code gets written today. Then we checked all nine apps with two scanners: axe-core, a common open-source tool, and Evinced Web Flow Analyzer, which digs substantially deeper.
Zero for nine on accessibility
Here are the results, in Table 1 below.
While some models fared better than others, the average number of accessibility defects in the built sites was 47 and the average number of critical defects was 21. For reference, at Evinced, the definition of a critical defect is one that would stop at least some assistive technology users from completing a task.
As bad as those averages are, three things in that chart matter more than the averages.
- There is no safe pick. Every model, in every framework, shipped bugs that block real users. Buying a “better” model or a “cleaner” framework does not buy you accessibility.
- The output is a lottery. The same GPT 5.1 that produced 8 bugs in plain JavaScript produced 90 in Svelte. Nothing about the request changed. When quality swings this wildly you do not have a process you can count on.
- Critical means locked out. Remember, a critical defect means the user is blocked from taking the intended action. Taylor Arndt, a blind developer with eight years in accessibility, gives a typical example: the AI puts an icon on something clickable and never labels it, so her screen reader announces only “button.” Button to do what? That is not a cosmetic flaw. It is a locked door, and the average app shipped 21 of them.
Why every model fails the same way
How does this happen? The answer is because AI models learn to write code by reading and learning from the web as it exists today. Here is what that teacher looks like:
| What WebAIM found (Feb 2026 scan, top 1M home pages) | |
| Home pages with detectable accessibility failures | 95.9% |
| Detectable errors per home page | 56.1 |
Train on that, and unlabeled buttons, missing image descriptions, and broken page structure look normal. Because statistically, they are normal.
“AI trained on an inaccessible web will reproduce that inaccessibility at scale, unless we intervene thoughtfully and intentionally.”
Aaron Gustafson, Microsoft
And so the loop feeds itself. AI-written code ships to the web; the web trains the next models. Left alone, the problem compounds.
Nobody is choosing this. Not the developers, who mostly never see the failures, and not the model vendors, who inherited the training data the same way we all inherited the web. It is a default, and defaults win unless something in the workflow pushes back.
This is a business problem, not just a quality problem
If your teams use Cursor, Copilot, Claude Code, or similar tools (and by 2026, most do), every AI-assisted feature ships with legal exposure under the ADA, the European Accessibility Act, and Section 508.
Is this “productive?” If productivity just means shipping more accessibility bugs faster, then that’s productivity we can do without.
“So just tell it to be accessible”
One way out of this potential mess, and one that engineering teams try often, is simply to ask the LLM to code more accessibly.
At first glance, this sounds like wishful thinking. But we tested exactly that, across all nine apps, just to be fair.
The results are in the next post in this series. Bring your favorite prompt.
Stay tuned.