Every automated accessibility check I have ever seen loads the page once, in whatever state the headless browser boots in: light colour scheme, no motion preference, forced colors off, desktop viewport.
That is one user.
I wanted to know what it costs, so I measured it across 36 public homepages — W3C, MDN, React, Vue, Kubernetes, GitHub, Wikipedia, GOV.UK, the BBC, a handful of design systems.
Each site was loaded seven times.
One run is the baseline: light, desktop, no preferences — what an ordinary pipeline tests.
The other six each change exactly one variable away from it.
A finding counts only if it exists in a non-baseline state and not in the baseline.
The result Sites that produced identical output across two identical runs (the control) 34 / 36 Of those, had a finding the baseline never surfaced 24 / 34 — 71% Had one axe classes as a violation, not "needs review" 16 / 34 — 47% Distinct findings missed by the baseline 296 Median per site 2 The median is the honest headline, not the
296.
The distribution is badly skewed: half the sites have two or fewer, and seven carry most of the volume — Vercel (72), Tailwind CSS (52), Radix UI (40), Wikipedia (31), TypeScript (17), Stripe (17), NASA (14).
Quoting the total alone would imply everyone is sitting on dozens.
They are not.
Six sites were clean in all seven states: W3C, WebAIM, MDN, Playwright, Primer, GOV.UK.
Four of them either write the standard, teach it, or are bound by a public-sector accessibility duty.
The control is the part that makes this a study Real sites carry carousels, rotating promos, A/B tests and lazy-loaded media.
Two identical loads do not necessarily produce identical output.
Without measuring that, "unique to dark mode" might just mean a different hero image rendered.
So I ran the same state twice, changing nothing, on all 36 sites: 7 findings appeared and 2 disappeared — all of them on two sites.
The other 34 were byte-identical.
The signal clears the noise by roughly forty to one.
The two unstable sites are named in the data and excluded from the headline rather than quietly left in the denominator.
If that number had come back at 50 instead of 7, there would be no article.
What exposed the findings Variable Sites Distinct findings Narrow viewport (mobile / 320px reflow) 26 301 Dark colour scheme 25 270 Dark scheme alone — no narrow state found it 9 31 Reduced motion 4 10 Forced colors 1 2 The first two overlap heavily — a lot of sites break in dark mode and at 320px — which is why "dark scheme alone" is broken out.
On those 9 sites the colour scheme is the only variable that can explain the finding.
By rule: on 22 sites, then , , , and 3 sites whose document is genuinely wider than a 320px viewport.
I got the counting wrong first, and the error was a factor of three Worth writing down, because the wrong way is the obvious way.
My first pass summed the per-state counts.
But a defect caused by a narrow layout appears in , and — three states, one element.
I was counting it three times.
The tell was in the raw output: Wikipedia showed exactly 30 incomplete results in each of those three states.
Not similar numbers.
Identical ones.
Had I published, I would have claimed "210 findings on Vercel".
The real figure is
72.
Findings are now keyed by and deduplicated across states.
The same mistake had a second half: attributing a finding to a single state when three overlapping states could equally claim it.
Attribution is now by variable group.
What this is not Not an audit. axe detects a minority of WCAG failures — 57% by issue volume in Deque's own study, roughly a third by success criteria.
Every number here is a lower bound on a subset.
Not a claim that any site is inaccessible.
A finding is not a failure, and an result is explicitly a request for human review.
Not a ranking.
The gap is a property of how pipelines are configured, not of how much any team cares.
That is exactly why the sites that write the accessibility standards came out clean: they are