"The AI wrote it, it should be fine."
We hear some version of that sentence almost every week now. A product team ships a new signup flow, a marketing page, a whole storefront, built in a weekend with an AI coding assistant doing most of the typing. Nobody reviewed the markup line by line. Why would they? The code compiles, the layout looks right, the demo went great in the meeting.
This is quietly becoming the new version of "the overlay will handle it." Except this time the risk is not a widget bolted onto a finished site. It is baked into the foundation, shipped at a scale no single developer could ever type by hand, and repeated across every page the tool touches.
Here is the uncomfortable part: the research does not say AI-generated code is universally bad at accessibility. It says something more specific, and more useful. AI is decent at the easy, visible stuff. It is consistently weak at the exact interactions that need a real human accessibility review the most.
The Stat: A study evaluating GPT-4o and Qwen2.5-Coder found that LLM-generated code handles basic accessibility features like color contrast and alt text reasonably well, but struggles with more complex issues such as ARIA attributes. (Source: arXiv 2503.15885)
Why "the AI wrote it" is not a QA plan
Think about what an AI coding assistant is actually optimizing for. It has seen millions of examples of good-enough markup, and it has learned the patterns that show up most often: a reasonable text-to-background contrast ratio, an alt attribute on an img tag because that pattern is everywhere in its training data. Those are pattern-matching wins, and the research confirms the model is genuinely decent at them.
But accessibility is not only about the presence of an attribute. It is about whether that attribute does the right job in context. Does the ARIA role actually match the widget's real behavior? Is the label programmatically tied to the input it describes, or does it just sit near it visually? Does keyboard focus move somewhere sensible when a custom modal or dropdown opens, or does it vanish into the page? These are judgment calls, not boilerplate, and judgment calls are exactly where the research says AI-generated code breaks down.
What the research actually found
We are not extrapolating from a hunch here. Three separate pieces of evidence point at the same gap from different directions.
| Source | What it found | Why it matters |
|---|---|---|
| arXiv 2503.15885 (GPT-4o and Qwen2.5-Coder study) | Handles color contrast and alt text reasonably well; struggles with complex ARIA attributes | The easy, high-frequency patterns get learned; the contextual judgment calls do not |
| CHI 2026 paper (Chen, Lu, Wang, Qiu, Chen, Yang) | Screen reader users completed real-world tasks less successfully with AI-generated image descriptions than human-written ones | The AI descriptions emphasized the wrong details or left out what actually mattered to the user |
| WebAIM Million (2026) | 95.9% of the top one million home pages have detectable WCAG 2 failures, averaging 56 errors per page | This gap is not new or AI-specific, but AI-assisted development can now reproduce it faster than ever, across more pages, with fewer human eyes in the loop |
That CHI 2026 finding deserves a second look, because it is the kind of result that should reframe how teams think about "AI wrote the alt text, so we're covered." The researchers were not measuring whether an alt attribute existed. They were measuring whether a real screen reader user could actually complete a real task using the description the AI wrote, compared to a human-written one. Completion rates dropped. Not because the AI omitted the attribute, but because it emphasized the wrong details or skipped what actually mattered to the person relying on it. Presence is not the same thing as usefulness, and that distinction only shows up when someone tests with real assistive technology, not when someone scans for the attribute's existence.
The pattern connects directly to what we found when we read our hands-on test of an AI-generated form: the visible pieces looked fine, and the parts that actually determine whether a screen reader or keyboard user can complete the task were the parts that failed.
That said, the research is not all bad news for AI tooling. The same arXiv paper that documents the ARIA gap also describes a feedback-driven method (the authors call it FeedA11y) that significantly outperforms standard one-shot prompting for producing more accessible code. The takeaway is not "never use AI to write code." It is "do not treat one-shot AI output as a finished, reviewed product," which, if you think about it, is the same standard you would hold a junior developer's first pull request to.
A pre-launch checklist for AI-assisted builds
If your team is shipping pages or features built substantially with AI coding assistance, here is where to point your review, based on exactly where the research says the gap sits:
- Every custom widget (modal, dropdown, tabs, accordion) has focus management tested with an actual keyboard, not just visually inspected
- Form labels are checked for programmatic association (
for/idoraria-labelledby), not just visual proximity to the input - Any non-trivial ARIA usage is checked against WCAG's own Understanding documents for ARIA-related criteria rather than assumed correct because the attribute is present
- Alt text and image descriptions are spot-tested with a real screen reader for whether they convey the detail a user actually needs, not just whether the attribute exists
- Color contrast and basic semantic HTML are still verified, even though this is the category AI tends to get right, because "tends to" is not "always"
- A human accessibility reviewer signs off before launch, the same way a security reviewer would sign off on AI-generated code touching authentication
It is worth putting these numbers side by side. Ninety-five point nine percent of the top one million home pages already have detectable failures, per the WebAIM Million report, and that number was built on a decade of mostly human-typed code. AI-assisted development does not change the ceiling on quality by itself. It changes the speed and volume at which a gap can be reproduced. A pattern that used to take a team of developers months to ship across a site can now happen in an afternoon, across every template the AI touches, unless someone is specifically looking for it.
The point is not to slow down
None of this is an argument against using AI to write code. It is an argument against treating AI output as a finished product instead of a fast first draft that still needs the review any first draft deserves, especially on the interactions the arXiv study on human vs LLM-generated code accessibility flags as the hard part: complex ARIA, real label association, and focus behavior in anything custom-built.
If your team has shipped anything meaningful with AI coding assistance in the last few months, it is worth a second look before more traffic hits it. Get a real audit before you ship AI-generated code and find out exactly where the gap is, while it is still cheap to fix.