AI Website Builders Are Failing Accessibility Audits
By The WAALEE Team · · 4 min read
In September, AudioEye asked five AI tools, OpenAI, Anthropic, Google, xAI and Lovable, to each build three sites to the WCAG 2.2 AA standard: a news page, an online store, a financial services page. All fifteen sites failed Level A, the most basic conformance tier there is. Testers logged 306 distinct issues, showing up more than 59,000 times across the pages, and 91% of them were medium or high severity. Telling the model to "build it accessible" barely moved the needle.
This isn't a fringe problem, it's the default web
It's not just AI output, either. The WebAIM Million 2026 report, an automated scan of the top one million home pages, found 95.9% have detectable WCAG failures, up from 94.8% the year before. The average page now carries 56.1 errors, and the single most common one, appearing on 83.9% of pages, is low-contrast text. A separate accessiBe audit of two AI-built storefronts found the same critical failures on both, regardless of how detailed the prompt was. Different tools, same failure shape.
Why contrast specifically keeps breaking
- A model picks colors for vibe, not ratio. "Soft lavender on off-white" reads as tasteful to a language model; it doesn't compute whether that pairing clears 4.5:1 against body text.
- Contrast math has no hook in a prompt. Nobody writes "make sure foreground and background pass WCAG AA" into a design brief, so nothing forces the check at generation time.
- Brand gradients are the worst offenders. Light text over a mid-tone gradient looks fine in the hero mockup and fails the moment the gradient shifts toward its lighter end.
- Each new screen re-guesses. Without a fixed palette to match against, color choices drift screen to screen, so even a site that starts compliant doesn't stay that way.
Your live site already solved this, if it's live
Here's the part most teams miss: if your current site has been up for a while and nobody's filed an accessibility complaint, its color pairs are a working data point, not a guess. The text that's readable on your homepage right now has already survived real eyes on real screens. That's a stronger starting point than asking a model to invent a new palette from a one-line brand description, because a new palette is a new, untested bet on contrast, every single time.
Extracting your actual deployed tokens, foreground and background pairs included, and handing those to Claude, Lovable, v0, Cursor or Bolt as fixed values removes the step where the model is quietly inventing color combinations no one has checked. It doesn't replace a real audit, and a site that's already failing contrast will just hand that failure forward. But it closes off the most common new failure mode: a model picking a brand-new, unverified pairing because nothing told it not to.
Three different ways to catch the contrast problem:
- AudioEye: Accessibility testing and remediation platform. Ran the five-tool study; good for auditing a site after it's built, not for stopping bad tokens at generation time.
- accessiBe: Accessibility overlay and audit vendor. Its gen-AI storefront audit is the clearest side-by-side look at how consistent AI's contrast failures really are.
- WAALEE: Extracts the color pairs your live site already uses as fixed tokens, so an AI builder matches a tested palette instead of inventing an unverified one.
The fix is boring, which is why it works
Run a real contrast check once, fix what's broken, then lock the result into a token file your AI tool reads on every generation instead of re-deciding colors from scratch each time. It won't make a model understand WCAG. It just removes the one decision it was never equipped to make correctly in the first place.