Not by default. In AudioEye's 2026 study, five AI tools each built three sites to a WCAG 2.2 AA brief, and all 15 failed Level A, the most basic tier, averaging 55 issues per page. WebAIM's 2026 scan of a million home pages found errors rising for the first time in six years. Ask for accessibility, then test keyboard, focus and screen reader output yourself.
What the studies found#
| Study | What was tested | Finding | Published |
|---|---|---|---|
| AudioEye, AI coding tools study | 5 AI coding tools, 3 sites each, briefed for WCAG 2.2 AA | All 15 sites failed Level A; 55 issues per page on average; 306 distinct issues seen more than 59,000 times | 2026, report covered by Stacker on 13 Oct 2026 |
| AudioEye, same study | Severity of those issues | 91% medium or high severity; 33% block a task outright; 13 of 15 sites shipped at least one task-blocking issue | Same |
| AudioEye, same study | AI-built online stores | 174 issues per page, against 55 across all the AI-built sites | Same |
| AudioEye, companion survey | Developers and business leaders | 81% confident their AI-generated code meets accessibility standards | Same |
| WebAIM Million 2026 | Top 1,000,000 home pages, automated WAVE scan | 56.1 errors per page, up 10.1% from 51 in 2025; 95.9% with detected WCAG 2 failures, up from 94.8% | 2026 |
| Veracode GenAI Code Security Report | 80 coding tasks, 100+ language models | 45% of code samples failed security tests; cross-site scripting not defended in 86% of relevant samples | 30 Jul 2025 |
AudioEye sells accessibility tools, so read its numbers as a vendor's study; the method (same brief, five tools, automated scans plus testing) is described in its write-up. WebAIM's scan is automated, so it counts only errors software can detect; the real failure rate is higher, not lower.
What fails, and why#
The AudioEye write-up names the same problems on site after site: links with no description, buttons a screen reader cannot identify, and form fields with no label. Its third finding is the useful one for builders: the tools often wrote the code that describes an accessibility feature but not the behavior the code promises. That is the kind of gap to look for: a dialog with role="dialog" whose focus never moves in or comes back, or a menu with ARIA attributes and no arrow keys.
WebAIM says the rise in errors likely reflects bigger, more complex pages, more third-party frameworks, and AI-assisted coding. Models learned from that web, and the AI-built sites in the AudioEye study landed close to its average.
Agents make it matter more. OWASP's Top 10 for Agentic Applications (December 2025) lists human-agent trust exploitation, where confident explanations lead people to approve harmful actions. An approval step a keyboard or screen reader user cannot operate, or cannot read, is one they approve blind or cannot approve at all.
What to check before you ship AI-built UI#
- Keyboard only. Unplug the mouse. Reach every control with Tab, open and close every dialog and menu, and submit every form.
- Focus. It moves into a dialog when it opens, stays there, and returns to the button that opened it.
- Names. Every button and link reads as what it does in a screen reader, not "button" or "link".
- Labels and errors. Every field has a label; errors are announced, not only colored red.
- Loading states. A button that is working keeps focus (
aria-busy, notdisabled), so keyboard users are not dropped to the top of the page. - Reduced motion. With the system setting on, nothing slides, bounces or loops.
- An automated scan, then a person. Scans catch missing names and contrast; only testing catches broken behavior.
Where a component library helps#
A library cannot make a whole app accessible, and none of the studies above tested one. What it changes is where the behavior lives. A dialog, menu or approval card written once, tested for keyboard, focus and screen readers, and installed as source does not depend on a model remembering focus management on the 40th prompt. PixilUI items are built on Base UI primitives where a primitive exists (dialog, popover, tooltip); keyboard, screen reader, reduced motion and dark mode are done for every item, and each item's page lists its keyboard map. Check them the same way you check your own code.
Questions#
Does asking the AI for accessible code fix it?
Not in AudioEye's study: the brief asked every tool for WCAG 2.2 AA, and all 15 sites still failed Level A. Asking helps the model add attributes; it does not test the behavior those attributes promise.
Which AI tools did the AudioEye study test?
Five AI coding tools from major model makers and app builders, named in AudioEye's write-up; each built a news site, an online store and a financial services site to the same brief.
Is the web getting less accessible?
WebAIM's 2026 Million report found 56.1 detectable errors per home page, up 10.1% on 2025, and 95.9% of pages with detected WCAG 2 failures, the first increase after six years of small improvements.
Is AI-generated code also less secure?
Veracode's 2025 report found 45% of AI-generated code samples failed its security tests across more than 100 models, and cross-site scripting went undefended in 86% of relevant samples.
Related#
- Why AI-built apps look the same, and what to change: the visual side of the same defaults.
- React component libraries for AI agent interfaces: libraries that ship the agent moments as source.
- Human-in-the-loop approval for AI agents: an approval step everyone can operate.
Sources#
- Stacker for AudioEye: Study: AI coding tools do not write accessible code (published 13 October 2026), read 4 November 2026
- WebAIM: The WebAIM Million, 2026, read 4 November 2026
- Veracode: We Asked 100+ AI Models to Write Code (30 July 2025), read 4 November 2026
- OWASP GenAI Security Project: OWASP Top 10 for Agentic Applications (9 December 2025), read 4 November 2026