What this page is for
Here is the claim this site exists to prove: a service reporting 99 % accessibility can still fail roughly a quarter of the people who try to use it. It sounds wrong. It is arithmetic.
That only lands if two ideas already make sense, so this page teaches both at once. Left: how independent things combine. Right: who digital accessibility is actually for, and what the standard requires.
Beat 0 of 6 revealed. Nothing is hidden from you — the same content follows in order.
The two ideas, beat by beat
Each row is one idea, seen from both sides. Read across a row, not down a column — the right-hand cell is the left-hand cell wearing different clothes.
The mathematics column. Six ideas, revealed one at a time.
The accessibility column. Each row pairs with the one beside it.
Beat 1 — how things combine
Each new choice multiplies the possibilities
Flip two coins. Each can be heads or tails. How many outcomes are possible?
2 coins × 2 outcomes = 4 outcomes
That is all a permutation is: the ways things can combine.
Beat 1 — who this is for
Accessibility is about people, not checkboxes
Digital accessibility means a service works for everyone who needs it. That includes people with disabilities.
- Vision screen reader
- Hearing captions
- Motor keyboard, switch
- Cognitive plain language
- Speech not only by voice
About 1 in 4 US adults has a disability. The US Census counts 45.8 million people of all ages (ACS 2024).
They are your users whether or not your analytics show them. A screen reader user. A keyboard-only user. Someone with a migraine today. Someone holding a baby.
Beat 2 — when one thing doesn't affect the next
Independent events multiply
Flip a coin twice. The first flip landing heads tells you nothing about the second. The flips are independent.
When events are independent, the chance of both happening is the product of their chances:
both heads = ½ × ½ = ¼ = 25 %
This is the rule the whole page rests on. Remember it.
Beat 2 — four things that must all work
Accessibility has four parts, and you need all four
WCAG — the international accessibility standard — groups its rules into four principles:
- PerceivableCan I take the information in?
- OperableCan I work the controls?
- UnderstandableCan I follow it?
- RobustDoes it work with my technology?
A site that is perceivable but not operable fails. You need all four — exactly the same "and" as the two coin flips.
Beat 3 — the multiplication bites
99 % each, many times, is not 99 % overall
A 30-step form where each step works 99 % of the time:
0.99 × 0.99 × ... 30 times = 0.7397
So all 30 steps work only 74 % of the time. The other 26 % of journeys hit at least one failure.
Each step looked nearly perfect. The journey does not.
Beat 3 — a benefit form is a chain
You cannot skip a step and still finish
Applying for a benefit is a sequence: check eligibility, prove who you are, enter your finances, upload documents, sign, confirm.
Get stuck at any one of those and you cannot apply. There is no partial credit and no way around it.
So the number of steps is not a detail. Every step is one more chance to lose someone.
Beat 4 — combining more than two
The same rule, all the way up
The rule does not change as things get bigger. For any number of independent steps, you multiply their chances together.
Notice that word independent — each step its own coin. Thirty steps, thirty coins. Whether a real form works that way is the question a later section asks.
The more steps, the faster it drops. Going from 99 % per step to 99.9 % — a ten-fold improvement — lifts the whole 30-step journey from 74 % to 97 %.
Fixing the step fixes the journey. That is the leverage.
Beat 4 — disability is not one fixed thing
It is permanent, temporary, or situational
The same barrier is met in three ways:
- Permanent — someone who is blind.
- Temporary — someone recovering from eye surgery.
- Situational — anyone squinting at a screen in bright sun.
The last one includes you. And because disability rises sharply with age — 46 % of people over 75 — most of us will meet it personally.
Beat 5 — not every failure is a wall
Three kinds of harm
- Total blocker — no way past. A drag-only upload with no keyboard alternative. The journey just ends.
- Partial blocker — a way past exists, but not for everyone. A date-picker that needs a mouse.
- Degrader — slows people down, stops nobody. Low contrast is the classic example.
Only the first kind shows up as "the user failed". The other two cost you people quietly, and no report counts them.
Beat 5 — why a green tick fools people
Automated tools only check part of the job
Tools like Lighthouse, axe and WAVE are useful — but everyone agrees they only catch 30–40 % of problems. The rest need a human who knows the standard.
A perfect score means "nothing this tool knows how to check is broken."
It does not mean the task works. The walls — keyboard traps, drag-only uploads — are mostly in the part no tool can see.
Beat 6 — the two ideas are one idea
Same arithmetic, different words
Permutations multiply because independent things must all work.
A journey multiplies because every step must work, and all four accessibility principles must hold.
Both are the same "and". Both multiply. Neither averages.
Beat 6 — so what?
A 99 % score can fail a quarter of your users
Put the two columns together and the conclusion is arithmetic, not opinion:
99 % per step → 74 % of journeys complete
And that is before counting the walls that stop people outright while the score never notices.
Ready for the proof? The next page runs all 30 steps.
That is the whole argument. The beats state it. The running example below lets you watch it happen, one click at a time.
Feel it: a running example at 1 %
Reading "0.99³⁰" is abstract. Clicking through it is not. Below is a short journey — a benefit application, the same shape as the full 30-step task — where every step has a 1 % chance of going wrong. That is the vendor's number: 99 % per component.
Press "Attempt step 1" and keep going. A 1 % failure rate will mostly pass. Occasionally it will not — and what happens next depends on what kind of defect it was, which is the second half of the argument. Watch the running total, and notice that it never comes back down.
The honest note the whole project rests on. At 1 %, most single runs pass every step. That is exactly why the problem is invisible to the person checking one page, and invisible to the vendor reporting one number. The injury is not in any single run — it is in the 26 % of journeys. Run it a few times and watch the odds turn against you.
What this example is, and is not.
- The 1 % is illustrative. It is the industry-standard headline number — "99 % accessible" — not a measurement of any real service. No service was audited to produce it.
- The eight steps are illustrative too. They are the shape of a benefit application, written to make the arithmetic visible. They are not a transcript of a real journey.
- What is not illustrative is the arithmetic. Once you fix a per-step failure rate, the compounding is not a matter of opinion — it is the third line of the page, and it holds at any rate you choose.
- 1 % is generous, not harsh. Real pages carry far more than one defect per step. See below.
Why 1 % per step is the optimistic case
The example above gives every step a 1 % chance of failure, and treats each step as a single component. Real services are worse than that on both counts, and the evidence for this is not a model — it is an annual crawl of one million live home pages.
| Measure | Value | What it tells us |
|---|---|---|
| Detected errors per home page (average) | 56.1 | Not one defect per page. Fifty-six. |
| Home pages with detectable WCAG 2 failures | 95.9 % | Failing is the norm, not the exception. |
| Average page elements per home page | 1,437 | Up 14.3 % in a single year. |
| Elements carrying a detected error | 3.9 % | One error in every 26 elements a person meets. |
| Errors on pages that use ARIA vs pages that do not | 59.1 vs 42.0 | Complexity, not intent, drives the count. |
These are counts of what automation can see. Roughly 30–40 % of issues are reachable by a scanner at all, so the true figures are higher — and the gaps are exactly where the walls live.
The report's own conclusion is the point of this page, in one line: home pages are getting larger and more technologically complex, and complexity correlates with more errors. The same year-over-year increase held for ARIA usage. A longer, richer journey is not the same journey with more steps — it is a journey with more error opportunities per step.
So the running example above is the best case. Set the quality dial to 97 % or 95 % in the simulation and the same compounding runs against a much higher rate. The argument does not need the worst case. It only needs the arithmetic and an honest input.
Not started — 0 of 8 steps attempted
P(all clear so far) = 0.99⁰ = 100.00 %
Journey failure risk accumulated so far
Where the running example's defects come from
Each step is a real defect class, cited. The probability that any given run hits a particular one is 1 %, because the build is "99 % accessible" — the point is not that these are likely, it is that a multi-step journey gives failure many chances to happen, and that the three failure types produce completely different endings.
That last point is worth sitting with. "How many users failed?" is the number everyone tracks, and it counts only the total blockers. The partial blockers and degraders — the ones that cost minutes, spoons and willingness rather than the whole attempt — never appear in it. The number everyone reports misses most of the harm.
"99 % accessible" — 99 % of what?
A number like 99 % sounds precise. It is only as good as the question it answers, and five different questions get called "accessible". They are not the same thing, and no single tool answers all of them.
-
1 What is actually accessible
Can a real person, using their own setup, finish the task? This is the only layer that is about outcomes, and the hardest to measure. Nobody puts a percentage on this — that absence is the reason this site exists.
-
2 Agreed best practice
Advice from practitioners and design systems that is widely agreed to help but is not required by any standard. Following it is good. It is not conformance.
-
3 What a standard requires — WCAG 2.2 AA, EN 301 549
A defined set of testable success criteria. Meeting all Level A and AA criteria is what "conforms to WCAG 2.2 AA" means. EN 301 549 is the European standard that adopts WCAG for public-sector and regulated procurement.
-
4 What automated testing can find at all
Automation is good at mechanical checks — missing alternative text, contrast values, duplicate IDs. GSA estimates around 30 % of success criteria are fully automatable. The rest need a person.
-
5 What axe actually returns today
The most widely used testing engine. Crucially, axe deliberately reports only what it can be certain about — it suppresses rules that would produce false positives. That is the right engineering decision, and it makes the green tick narrower still.
The bar lengths show relative breadth only. No tool or standards body publishes a tested percentage for each layer, so the widths are an illustration, not a measurement.
Why the top layer is the one that matters here
Layers 3 to 5 are all countable, which is why they end up in dashboards. Layer 1 is not, so it usually goes unmeasured. A service can pass layer 5 completely, comply with layer 3 on every criterion a scanner can reach, and still lose layer 1 for the people who needed it most — and report a score that looks excellent.
This is the same distinction the simulation draws between a WCAG failure and a wall: they overlap, but neither one contains the other.
Is it 30 coins, or one coin used 30 times?
Beat 4 used the word independent: each step its own coin. That is an assumption, and it is worth showing what it is worth, because this one question changes the answer more than any other input on this site.
Real services reuse things. A footer, a navigation block, a page template, a component from a design system — the same code, on many steps. Shared code can mean a shared defect. No source in this project measures how often that happens, so treat the sharing levels below as illustrations of a question rather than estimates of a real service.
| Reading | Distinct coins | Risk of failing somewhere |
|---|---|---|
| Every step its own coin (as published) | 30 | 26.03 % |
| 10 steps shared, 20 unique | 21 | 19.03 % |
| All 30 steps shared | 1 | 1.00 % |
Counting a shared element once — which is what "repeated elements count once" means — drops the figure from 26 % to 1 %. That is not a rounding difference. It is a different question: how many distinct things can fail? rather than how many chances does this journey give failure to happen?
Which reading is right — and what we could not find out
We do not know, and neither does anyone else. No published source states what fraction of a real service's steps are served by shared code, so the number cannot be looked up. That is why the site keeps the more conservative reading: a service that reuses one broken component across 30 steps has not thereby become safer for the person who meets it 30 times.
A correction worth recording. The first version of the arithmetic behind this section also claimed a third reading — that a shared element was worse still, because once broken it fails on every use. That claim was wrong. "Counted once" and "same coin used many times" are the same algebra: both give 1 − 0.99(N − g + 1). A 200,000-trial simulation agreed with the closed form to within 0.17 percentage points at every level of sharing. The invented third reading was removed rather than shipped, because a number that cannot be derived is exactly the kind of thing this site exists to argue against.
The simulation on the next page carries this as a stated assumption. See computeSharedElementModel in cumulative-accessibility-risk-simulator.html.
Where to go next
If both ideas already make sense, nothing here is required reading — move straight to the simulation, which is the evidence. If one column landed and the other did not, the reveal controls replay any beat.
A 30-step interactive journey with persona controls, and the deterministic population calculation with cited inputs.
Sources for this page
- CDC, Disability Impacts All of Us / DHDS (BRFSS 2022): 28.7 % of US adults report a disability.
- US Census Bureau, American Community Survey 2024 (via Disability Statistics): 13.6 % of all ages, 45,846,700 people.
- Census ACS 1-year estimates / Pew Research 2023: disability prevalence 12 % (18–64), 24 % (65–74), 46 % (75+).
- Microsoft Inclusive Design, Persona Spectrum: permanent, temporary, situational.
- W3C, WCAG 2.2 — the four POUR principles.
- EN 301 549 — the European standard that adopts WCAG for public-sector and regulated procurement.
- GSA (≈30 % of success criteria automatable) and Deque (≈40 % of issues).
- WebAIM Million, 2026 (February 2026 crawl): 56.1 detectable errors per home page; 95.9 % of home pages with detectable WCAG 2 failures; 1,437 page elements per page on average; pages with ARIA averaged 59.1 errors against 42.0 without.