Human-in-the-Loop: Why AI Coding Assistants Are Failing Holiday Accessibility Audits

The holiday release is due Friday. A developer asks an AI coding assistant for a promo banner, a gift-wrap toggle and a "Notify me when back in stock" modal. Ten minutes later the components look perfect, pass the build and ship. Then the first screen reader user arrives, and the modal can't be closed, the toggle is announced as "clickable" and the banner's offer is an image with no text alternative.

AI has become part of almost every development workflow, including accessibility. But the models writing our components learned from the web as it is, and the web as it is fails accessibility checks on almost every page. This post looks at why AI accessibility tools and AI coding assistants still need a human in the loop, the real difference between automated remediation vs manual testing, and how to build an integrated accessibility strategy that keeps your digital accessibility risk footprint small during your busiest release season.

AI is everywhere in accessibility work

Level Access's State of Digital Accessibility Report for 2025–2026 found that 82% of organizations say they use AI tools in their accessibility strategies, up from 79% a year earlier. Its 2026–2027 edition puts the share of professionals using AI for accessibility work at about 80%, but notes that no single use case has been adopted by more than a third of them. In other words, almost everyone is experimenting, and nobody has a single answer.

That's not a reason to avoid AI. Used well, it can explain a WCAG criterion in plain language, draft alt text for a human to edit, suggest ARIA patterns and speed up fixes across a large codebase. The risk is treating its output as finished and accessible because it looks finished.

Trained on a broken web

Large language models learn to write code by studying huge amounts of existing code and web pages. The trouble is what that code looks like. The 2026 WebAIM Million found detectable WCAG failures on 95.9% of the top one million home pages, with an average of 56.1 errors per page. And those are only the errors an automated tool can detect.

So when an assistant generates a dropdown, a modal or a product card, it reproduces the most common way those components are built, which is often the inaccessible way. WebAIM's authors went further. They suggested that the rise in errors since 2025 likely reflects changes such as automated and AI-assisted coding practices. That's an explanation, not a measured finding, but it points to a feedback loop. AI learns from inaccessible code, generates more of it, and that code becomes part of the web future models learn from.

The same report found that home pages using ARIA averaged 59.1 errors, compared with 42 on pages without it. ARIA isn't bad, but it's easy to misuse, and AI assistants tend to add it generously.

Where AI-generated code fails

The pattern is consistent: AI-generated components usually look right and often pass a quick automated scan, but break in ways only a keyboard or screen reader test reveals.

Each of these is easy to fix once someone notices it. The problem is that nobody notices if the only reviewer is another automated tool.

The myth of the all-in-one AI fix

The same promise shows up every year: install one AI-powered tool and your site becomes compliant. It's appealing, especially in November. It's also not how accessibility works.

Automated tools, AI-powered or not, can only judge what they can measure. Studies of automated testing consistently find that a large share of real barriers needs human judgment. Whether alt text is accurate, whether focus order makes sense, whether an error message is understandable and whether a custom widget actually works with a screen reader all fall into that share. In 2025 the U.S. Federal Trade Commission ordered accessiBe to pay $1 million over claims that its AI-powered tool could make any website compliant. And UsableNet reports that about 20% of companies sued over digital accessibility in 2026 already had a widget or overlay installed.

The answer isn't AI or humans. It's AI and humans, each doing what they're good at.

A human-in-the-loop workflow for holiday releases

Holiday code is a special risk. It's written fast, often by people outside the core team, and shipped under pressure just before your highest-traffic weeks. Build accessibility checkpoints into the path from AI draft to production.

1. Prompt for accessibility.Ask for native HTML elements, visible labels, focus management and WCAG 2.2 AA explicitly. You'll get better drafts, but you still can't assume they're correct.
2. Automate the basics in CI.Run axe-core or a similar engine and an accessibility linter on every pull request, and block merges on new failures.
3. Review like it's a security change.A reviewer checks interactive components against a short checklist: native elements, names, roles, states, focus and error handling.
4. Test with assistive technology.Before merging, someone completes the component's task with only a keyboard and then with NVDA or VoiceOver. It takes minutes per component.
5. Include disabled users for key journeys.For checkout, account and booking flows, usability testing with people who use assistive technology every day finds problems no checklist will.
6. Document and monitor.Record what was tested and when, scan production after release, and give customers a clear way to report barriers.

<!-- Prompt the assistant with requirements, then verify by hand -->
"Build a back-in-stock modal using the native <dialog> element.
 Requirements: visible label on the email field, autocomplete="email",
 focus moves into the dialog on open and returns to the trigger on close,
 Escape closes it, the close button has an accessible name,
 errors are announced. Target WCAG 2.2 AA."

Frequently asked questions