Here is a bug almost too boring to write up: light gray text sitting on a plain white button. No exotic color theory, no obscure font stack, just gray-on-white failing WCAG's 1.4.3 contrast minimum. The kind of thing a developer fixes in thirty seconds without thinking twice.
So we didn't fix it ourselves. We took that exact CSS rule and sent it, unchanged, to four different AI models with the same one-shot prompt: fix this so it passes WCAG 1.4.3. We expected four confident, plausible-looking hex codes back. We got that. What we didn't expect was how differently "passing" would actually look once we ran the real relative-luminance math on each answer ourselves.
The Stat: WCAG's 1.4.3 Contrast (Minimum) requires a 4.5:1 ratio for normal text and 3:1 for large text and UI components. (Source: W3C WCAG 1.4.3)
The Setup: One Bug, Four Models, No Hints
The bug itself was deliberately unremarkable: #999999 text at 14px on a #ffffff background. We independently computed the real ratio at 2.85:1, well under the 4.5:1 floor WCAG sets for normal text.
We didn't tell any model what "good" looked like. We didn't mention a target ratio, a preferred palette, or a brand color. Just the CSS rule and one instruction: fix this so it passes WCAG 1.4.3. Then we took every proposed hex value and ran the actual relative-luminance contrast math ourselves, rather than trusting whatever number the model claimed.
That distinction matters. An AI model stating "this passes" and an AI model's fix actually passing are two different claims, and only one of them is checkable. It's also the distinction most teams skip under deadline pressure: a suggested hex code shows up in a pull request, it looks darker than the original, someone approves it, and nobody reaches for a calculator to confirm the number actually clears the line.
What Each Model Actually Proposed
Here's where it got interesting. All four models moved in the right direction, darkening the gray. But they didn't converge on the same answer, and they didn't all leave themselves the same room for error.
Model A proposed #767676 on white and claimed roughly 4.55:1. Our own computation put the real ratio at 4.542:1. That does clear the 4.5:1 minimum, but by only 0.042, less than 1% of headroom above the line.
Model B landed on the same #767676 as its primary answer, estimating 4.54:1, which lines up with our computed 4.542:1. What set Model B apart is that it didn't stop there. It separately flagged #595959, real ratio 7.005:1, as a safer alternative "if more margin was wanted," and it explicitly told us its own primary answer "passes by a hair." That's a meaningfully different kind of output: a fix plus an honest caveat about its own fragility.
Model C proposed #666666, which we computed at 5.742:1, comfortably clear of the minimum with no caveats needed.
Model D also proposed #666666 (5.742:1) and, like Model B, went a step further: it noted that #767676 was roughly the lightest gray that would still pass, sitting at the same razor-thin margin Models A and B landed on.
The Verdict: Everyone Passed the Math. Not Everyone Passed the Test That Matters.
Strictly by the numbers, all four models did the underlying contrast math correctly enough to clear 4.5:1. None of them shipped a fix that actually fails 1.4.3 today. If you only checked "does this number exceed 4.5," you'd call it four for four.
But that's the wrong question. Two of four fixes, Model A's answer and Model B's primary answer, pass by less than 1%. That's the kind of margin that real-world rendering can erase without anyone touching the "accessible" color value again: anti-aliasing differences across browsers, a font-weight tweak from 400 to 300, a designer nudging the background off pure white by a shade for a future dark-mode variant. Any one of those can tip a 4.542:1 under the line, silently, with no code review flag anywhere near it.
Only two of four, Models C and D, left genuine safety margin without being asked to. Model B is worth calling out separately here too: even though its primary pick was the fragile one, it volunteered the safer alternative and was transparent that its own answer was tight. That's a different failure mode than the other three; not a wrong answer, but a thin one, at least honestly labeled as thin in Model B's case.
This is a small, reproducible test we ran ourselves, not a formal industry benchmark, and we're not naming which commercial products sit behind "Model A" through "Model D" here. The point isn't to rank vendors. It's that "the AI said it passes" and "the AI's fix has room to still pass next quarter" are not the same guarantee, and right now you can't tell which one you got without checking the math yourself.
Why "Passes By a Hair" Is a Real Risk, Not a Technicality
A 4.542:1 ratio is not wrong today. It's fragile going forward. Contrast bugs rarely arrive alone; they show up again after a rebrand, a dark-mode launch, a new marketing template, or a well-meaning designer who lightens a border color by a few percent because it "looked heavy." A fix sitting at 4.542:1 has essentially zero cushion for any of that. A fix sitting at 5.742:1 can absorb a fair amount of drift and still land safely over the line.
This is the same gap we found when we looked at a broader question in our companion piece, Can AI Write Accessible Code?, where we tested four AI models against a wider set of accessibility tasks, not just contrast math. The pattern rhymes: AI output can be technically defensible while still being the riskier choice among several technically defensible options.
What To Actually Do With This
If you're using AI-assisted suggestions to patch contrast issues, a few honest habits go a long way:
- Never trust a stated ratio. Recompute it. A tool like WebAIM's contrast checker takes seconds and catches both wrong math and thin margins.
- Read the actual normative rule, not a paraphrase of it. The W3C's Understanding Success Criterion 1.4.3 page spells out exactly what counts as large text, UI components, and the required ratios.
- Build in margin on purpose. If a fix clears the minimum by less than 5 to 10%, treat it as unfinished, not passing. Push for the version with headroom, the way Models C and D landed on without being asked.
- Ask the model to show its ratio math, and check whether it flags its own fragile answers the way Model B did. That transparency is a signal worth rewarding.
None of this requires a redesign. It requires treating "passes" as a number you verify, not a claim you accept. The gap between 4.542:1 and 5.742:1 costs nothing to close at the design stage, a slightly darker gray is not a hardship, but it costs real remediation time later if a future update quietly drags a thin fix back under the minimum.
Get Your Own Numbers Checked
If you'd rather not run this experiment on your own production CSS, you don't have to. Our free tools will compute the real contrast ratios across your site the same way we did here, no guessing, no "passes by a hair" left unflagged.
And if you want an actual person to walk through your results with you, our team is reachable directly at experts@wcag.world. You can also start anytime with our free tools to see where your own margins really stand.