Ask an AI design tool to build you a "modern landing page" and most people already know what they expect to find wrong with it. Pale gray text on a white card. A button that's basically invisible until you squint. Low-contrast everything, because that's what "clean" and "minimal" have come to mean in a certain school of visual design.
That assumption is reasonable. It is also, at least in our own test, wrong. We asked an AI model to generate a landing page hero section with zero accessibility instructions, the exact way a product team actually prompts these tools on a Tuesday afternoon when they just want something that looks good fast. Then we didn't take its word for anything. We pulled the real HTML and CSS it returned and measured it ourselves.
The Stat: In our own real test, every text/background color pair in an AI-generated landing page we independently measured actually passed WCAG AA contrast, some by a wide margin, while the real gaps were structural: two undecorated emoji/icon glyphs, zero landmark main element, and five navigation links that went nowhere. (Source: our own real, reproducible test, detailed in the article below)
What we actually asked for, and what came back
We kept the prompt deliberately plain: build a self-contained "modern SaaS landing page hero section" in HTML and CSS. No mention of accessibility, no mention of WCAG, no hint that anyone would ever check. That's the point. Most teams shipping AI-generated UI right now are not typing "and make sure it's accessible" into every prompt. They're typing what we typed.
The model handed back a hero section with a logo mark, a headline, a short description, a call-to-action button, a badge with a little decorative flourish, and a row of navigation links. Visually, it was fine. Better than fine, honestly. Reasonable spacing, a coherent color story, nothing that screamed "AI made this in one shot."
So we stopped trusting the eyeball test and started measuring.
The contrast surprise
We computed the actual contrast ratio for every text and background color pairing on the page ourselves, using the relative-luminance formula rather than trusting any built-in claim. Every single pair passed WCAG AA. Several passed by a wide margin, with measured ratios ranging from 5.42:1 up to 17.94:1.
That's worth sitting with for a second. The assumption that AI page generators default to washed-out, low-contrast text turned out to be false in this test. These tools are trained on a huge volume of visually competent design work, and visual competence tends to include reasonable contrast almost as a side effect. Contrast is, in a real sense, easy to get right by accident when your training data is full of good-looking pages.
What isn't easy to get right by accident is anything that depends on knowing why an element exists rather than just how it should look.
Where the real gaps were
Here's what we actually found when we went element by element through the markup.
Two decorative glyphs were announced as if they were content. An emoji sitting inside a badge and a symbol used as the logo mark were both placed directly in the text, with no aria-hidden attribute. A sighted user reads past them without a second thought. A screen reader user hears them announced literally, word for word, right alongside the actual copy they're trying to parse.
A decorative SVG icon had no hidden signal either. Next to a line of descriptive text sat a small SVG glyph that carried no meaning of its own, it was purely visual reinforcement. But nothing in the markup told assistive technology that. Without an aria-hidden="true", the icon is ambiguous: is it decoration, or is it information the user is expected to act on? The WCAG technique for hiding decorative content exists precisely for this gap, and it went unused here by default.
There was no <main> landmark anywhere on the page. The markup had a <header>, and that was it structurally. For a screen reader user navigating by landmark, which is one of the most common navigation patterns there is, the page's actual content region simply doesn't announce itself as a destination.
All five navigation links pointed to href="#". Every single one. That's not a styling problem, it's a functional dead end. A mouse user clicking one of those links gets nothing. A keyboard user tabbing to one and pressing Enter gets nothing. A screen reader user hearing "link, Pricing" and activating it gets nothing. The ARIA Authoring Practices Guide is built around the idea that a control should do what it announces, and a placeholder href breaks that promise for everyone equally, not just for assistive technology users.
To its credit, the model didn't get everything wrong. The buttons it generated were real <button> elements, not clickable <div>s pretending to be interactive. And the stylesheet never explicitly stripped the default focus outline, which is a small thing but a genuinely common self-inflicted wound we see in hand-written code too.
The actual lesson here
The honest takeaway isn't "AI design tools are inaccessible." That's too broad, and this test doesn't support it. The honest takeaway is narrower and more useful: visual polish, including contrast, is often fine by default, because these tools are trained on visually competent examples. What doesn't happen automatically is anything that requires intent rather than aesthetics. Hiding decoration from assistive technology, building a landmark structure, wiring real destinations instead of placeholder hrefs, these all require someone to know why an element is there, not just how it should look. A visual generation tool has no channel for that information. It only ever sees pixels and patterns, never purpose.
This is the same pattern we've talked about before with hand-built interfaces, where a hamburger icon button looks complete on screen while missing the one label that makes it usable by everyone. AI-generated code just produces the pattern faster and at greater volume. If you're relying on agents to touch your front end more broadly, it's worth reading how AI agents can quietly break a site for screen reader users too, because the failure mode is consistent: structure and intent are the last things automated, not the first.
What to actually check before you ship AI-generated UI
If you're pulling hero sections, dashboards, or landing pages out of an AI design tool, don't audit for contrast first. Based on what we found, spend your time here instead:
- Search the markup for emoji characters and decorative SVGs sitting in or next to text, and confirm they carry
aria-hidden="true"if they add no independent meaning. - Check for a
<main>element wrapping the actual page content, not just a<header>and a pile of<div>s. - Click, or better, tab to, every single link and button the tool generated. If it resolves to
#, it isn't done. - Verify focus outlines are still visible. This one is often fine by default too, but it's cheap to check and expensive to lose.
None of that requires a specialist. It requires about ten minutes and a habit of actually looking at the HTML instead of just the rendered page. If you'd rather have that check run automatically across your whole site, including anything an AI tool has touched, that's exactly what we built AccessRadar to do, and you can run a scan at wcag.world/accessradar.
If you want to talk through a specific page or a specific tool's output with an actual person on our team, write to us at experts@wcag.world, or go run a scan yourself at wcag.world/accessradar.