AI-generated code is inaccessible by default

Code generated by AI assistants fails accessibility checks at high rates: in one peer-reviewed study, 84% of websites generated with ChatGPT contained WCAG violations. The reason is structural — models learn from a web where roughly 96% of pages have detectable failures — so accessible output is the exception, not the default. Teams shipping AI-written UI need automated scanning as a safety net, not as an afterthought.

Here's the evidence, with sources you can check.

The web that trains the models is 96% inaccessible

Large language models learn to write HTML, CSS, and component code from the code that exists. And the code that exists is broken: the WebAIM Million 2026 found detectable WCAG 2 failures on 95.9% of the top one million home pages, averaging 56.1 errors per page. Low-contrast text appears on 83.9% of pages, missing alt text on 53.1%, unlabeled form inputs on 51%.

So when a model completes a form, a card grid, or a modal, its statistical prior is the median pattern on the web — a pattern that, more often than not, fails WCAG. Nobody had to train the model to skip form labels. The training distribution did it.

This is a well-understood dynamic, and researchers studying LLM code generation state it directly: models "trained on vast datasets" of existing website code inherit and perpetuate the accessibility barriers in that code (Guriţă & Vatavu, W4A '25).

What the studies actually found

This isn't a vibe; it's been measured repeatedly.

84% of ChatGPT-generated websites had accessibility violations. Aljedaani et al. (W4A '24) had 88 web developers prompt ChatGPT to build websites, then audited the output. 84% of the generated sites contained accessibility issues, concentrated in perceivability: text resizing accounted for 31.8% of violations, insufficient contrast 26.6%, and missing semantic relationships 16.8%. Notably, when explicitly asked to fix its own errors, ChatGPT repaired about 70% of them — the capability exists, but it isn't exercised unless someone asks, and it degraded on harder criteria like contrast (60%) and info-and-relationships (59%).

Accessibility-focused prompting helps, but barriers persist. Guriţă and Vatavu (W4A '25) generated banking app UIs with ChatGPT and Claude under two conditions: a plain prompt and one with explicit WCAG requirements. Accessibility-oriented prompts improved several criteria — focus visibility success counts rose 233% — yet the authors conclude that "persistent barriers remain, particularly in semantic structure," and some criteria actually got worse under the accessibility prompt. Both models failed in similar ways, suggesting the limitation is in the underlying training, not any single vendor's model. They also tested LLM self-review: models were reasonably good at flagging their own contrast and structure issues but systematically under-reported keyboard navigation problems.

LLMs handle the easy criteria and stumble on ARIA. Suh et al. compared accessible-code generation in GPT-4o and Qwen2.5-Coder against human-written code and found the models often did fine on surface-level features like color contrast and alternative text but "struggle with complex issues such as ARIA attributes." Zero-shot, few-shot, and self-criticism prompting all produced only limited improvements; meaningful gains required a feedback loop driven by an external accessibility checker.

The pattern across all three: AI output looks plausible, passes the eyeball test, and fails the criteria that require understanding what an interface means — roles, states, relationships, keyboard behavior.

2026: the first regression in the WebAIM Million

Correlation isn't causation, but the timing is uncomfortable. After six straight years of small improvements, the 2026 WebAIM Million recorded the first reversal:

• Failure rate up (94.8% → 95.9%) and errors per page up 10.1% (51 → 56.1).
• Average page elements up 22.5% in a single year, to 1,437.
• ARIA attributes up 27% in one year — over 133 per page, six times the 2019 level. And pages with ARIA averaged 59.1 errors versus 42 on pages without it: markup that's supposed to signal accessibility work is correlating with more failures, which is what you'd expect when it's generated rather than understood.

WebAIM's own conclusion explicitly flags "automated or AI-assisted coding practices ('vibe coding')" — alongside growing reliance on third-party frameworks — as a likely contributor to the regression. That's the strongest attribution a careful, methodology-first outfit like WebAIM is willing to make, and it's worth taking at face value: not proof, but a credible warning from the people with the best longitudinal dataset on the subject.

The framework data in the same report cuts both ways: sites built on some modern stacks (Astro, Next.js, React) showed fewer errors than average, while pages using most popular JavaScript libraries showed more. Tooling can encode good defaults. Generated code mostly doesn't.

Why "just prompt it better" isn't a strategy

Every study above tested prompting as the fix, and every one found it partial:

• Explicit WCAG prompts improved some criteria and regressed others (W4A '25).
• Zero-shot, few-shot, and self-critique prompting produced limited gains; only checker-driven feedback loops moved the needle (Suh et al.).
• Models under-report their own keyboard and ARIA failures, so asking the model to review itself has a blind spot exactly where the hardest bugs live.

There's also an organizational reality: the developers most empowered by AI codegen — juniors, non-frontend specialists, "vibe coders" shipping whole features from a prompt — are the least likely to spot a missing aria-expanded in review. The volume of shipped UI goes up; the accessibility expertise per shipped component goes down.

None of this means AI codegen is unusable. It means the verification burden moves from the author to the pipeline — the same shift that already happened for security and type safety.

What teams shipping AI-written UI should do

1. Scan every build, not every quarter. The failures AI code ships most — contrast, labels, alt text, empty interactive elements — are exactly the categories automated WCAG scanning detects reliably. If AI writes some of your markup, scanning is your regression suite for it. Start by seeing what a free WCAG audit finds on your site today.
2. Treat findings as bugs, not reports. A PDF audit nobody owns changes nothing. Each failure needs an owner, the offending element, and a definition of done — the same QA workflow you use for functional defects.
3. Keep humans on the semantic layer. Automated checks and AI self-review both miss keyboard behavior, focus order, and ARIA correctness. Budget manual review for interactive components, especially generated ones.
4. Don't reach for an overlay. A widget layered on top of generated markup fixes neither the markup nor your legal exposure — we've covered why overlays don't protect you separately.
5. Give the model the feedback loop the research says it needs. Scanner output fed back into the generation or review step is the one intervention that consistently improved results in the studies above.

For the first two, this is precisely the loop BugPort automates: scheduled WCAG scans catch what your AI assistant shipped, each failure becomes a ticket with element-level evidence (selector, screenshot, the specific success criterion), and re-scans verify the fix actually landed. It's a safety net for AI-accelerated teams — not a substitute for the human review in step 3, and not instant compliance. If AI writes part of your frontend, a WCAG audit will show you what it's been leaving behind. Our accessibility guide covers how to build the rest of the program around it.

FAQ

Is AI-generated code accessible?

Not by default. In a peer-reviewed study, 84% of websites generated with ChatGPT contained accessibility violations, and follow-up research across ChatGPT, Claude, GPT-4o, and open models found the same pattern: passable on contrast and alt text prompting, weak on ARIA, semantic structure, and keyboard behavior.

Can better prompts make LLMs write accessible code?

Partially. Research at W4A '25 found accessibility-oriented prompts improved some WCAG criteria while others regressed, and Suh et al. found prompting strategies alone gave limited gains — the reliable improvement came from feeding automated checker results back to the model. Prompting helps; verification is what works.

Why do LLMs produce inaccessible markup?

Because they learn from the existing web, and the existing web fails: the WebAIM Million 2026 found WCAG failures on 95.9% of top home pages. Models reproduce the median pattern in their training data, and the median pattern is missing labels, low contrast, and decorative ARIA.

Is AI making web accessibility worse overall?

The 2026 data points that way but doesn't prove it. The WebAIM Million recorded its first regression in six years — errors up 10.1% — and WebAIM explicitly named AI-assisted "vibe coding" as a likely contributor. Treat it as a credible early warning: teams generating more UI faster need proportionally more automated verification.