The proposition under test
A monitoring dashboard reports the portal is 99 % accessible. Every page tripod check for Lighthouse and axe-core returns a perfect 100. The press release says the service now "meets WCAG 2.2 AA."
The question this simulator answers: what is the probability that a single citizen completes the whole 30-step task — not one page, the entire journey?
Because a journey is a serial system, component reliability multiplies. A per-step pass rate of p = 0.99 yields 0.99³⁰ ≈ 73.97 % end-to-end completion. Hiding inside that headline percentage is a concrete injury to at least one person.
1. Citizen persona (assigned at random)
Each run draws one capability from each of the four Persona Spectrum domains, then one severity level — Permanent, Temporary, or Situational. A persona with more than one active constraint experiences compounding risk, not additive risk.
Not yet generated
- Current step 0 / 30 Not started
- P(journey failure) — general user 0.00 % 1 − (1 − p)ⁿ
- P(journey failure) — this persona 0.00 % multi-domain compounding applied
- Defects revealed 0 no defects revealed yet
Run state — the citizen's finite capacity
Spoon Theory: a citizen has a finite pool of capacity for one journey. Each barrier draws it down. Nothing "fails" them — they run out, and then they stop, which is a different ending. The pool covers this form, not a whole day.
- Spoons remaining — / —
- Confidence in the service 100 %
- Time spent 0 min friction and retries only
- Interaction attempts 0 steps plus retries
Four ways a defect can treat a citizen
- TERMINAL Pass or fail. One roll, the journey is over. Example: a drag-only upload with no keyboard path.
- SPOON COST No wall at all. Each encounter drains a finite energy pool. Enough of them and the citizen gives up — an ending no conformance report records.
- EFFORT Recoverable, at a price: extra attempts, minutes, and confidence spent on working around the service instead of using it.
- FRICTION A genuine violation that stops nobody. Real, reportable, and not the reason anyone fails.
Five places the obligation comes from
- WCAG 2.2 A success criterion is failed.
- ACT RULE The standardised test surface — and where it silently passes.
- FPC Section 508 / EN 301 549 functional performance criteria, which describe the citizen rather than the code.
- SYSTEMIC A barrier entirely outside WCAG 2.2 — a policy, channel, device, language, or identity-proofing exclusion. No SC is violated and the citizen is still stopped.
- LAW / POLICY A statutory or business rule with no rendering requirement attached.
Bar chart of cumulative journey failure probability under two models: the general component model (p = 0.01) and the persona-weighted multi-domain model. The data table immediately below the chart is the accessible equivalent.
Accessible equivalent: cumulative completion data table
| Steps completed (n) | P(failure) general | P(completion) general | P(failure) persona |
|---|
How the persona-weighted probability is calculated
- Component model. Baseline defect rate p = 0.01 (99 % component-level accessibility).
- Defect clustering. Accessibility defects are not uniformly distributed. Automated tooling concentrates on the ~30 % of WCAG 2.2 A/AA criteria it can decide; defects concentrate in semantic structure, keyboard/focus management, and pointer interactions.
- Conditional exposure. For persona i with sensitivity
Ri to the affected criterion families:
pi = min(0.14, p × Ri) - Multi-domain compounding. A persona constrained in k domains carries pi = min(0.14, 0.002 × ΣRd).
- Journey model. P(failure) = 1 − (1 − pi)ⁿ — mathematically identical to hardware serial/availability reliability.
- Bound. Defects that are not merely friction but true task blockers (e.g. no keyboard path to a control) have pi = 1.00. For those, no probability reduces: the journey ends at that step, deterministically.
Ri denotes relative exposure to the defect families that matter for that domain — it is an explanatory weighting for the reliability curve, not a per-person clinical prediction.
3. The defensible calculation — population-level, deterministic
Everything above this point depends on how a persona is drawn. That is fine for illustration and useless for argument. This section contains no random draw at all: every figure is either a published statistic or a labelled assumption, and re-running it gives the same answer. If you disagree with the result, the disagreement belongs at the inputs — which are stated.
Three severities, not one
"Accessibility error" is not a single thing. The model separates three outcomes, because they have nothing in common mathematically:
- TOTAL BLOCKER No path exists. Removes 100 % of the affected Functional Performance Criteria group from the journey. Example: drag-only upload with no keyboard alternative, where SC 2.5.7 has no published ACT rule.
- PARTIAL BLOCKER A path exists for part of the group. Removes the share with no alternative route — a figure taken from survey data where one exists, and labelled as an assumption where none does. Example: pointer-only date-picker, which excludes the 60.4 % of low-vision respondents who navigate by keyboard.
- DEGRADER Blocks no one. Raises error and abandonment rate, which compounds over 30 steps. Example: low contrast, the single most-reported failure on the web.
There are no published numbers for partial-blocker fractions. This is a genuine gap in the evidence base, not an oversight here. No standards body publishes the share of a disability group that has no alternative path to a given widget. Every such figure in this model is therefore stated as an explicit assumption with a range, is listed in the assumptions table below, and is marked assumption in the defect record. The total blockers need no such assumption: the absence of a path is observable.
Inputs and their sources
| Input | Value | Source | Kind |
|---|
Result — completion by population group
This is the number that matters. Note that it is not the vendor's figure, and that it barely moves when component quality improves, because the dominant losses are unrecoverable walls rather than the friction that quality improvements address.
| FPC group | US adult prevalence | Loss to blockers | Group completion | Primary cause |
|---|
Population completion across the quality dial
The row marked unaided users is the number a compliance dashboard reports. The rows below it are the population, and the gap between them is the false assurance. The spread across automated-catch-rate assumptions is shown so the extrapolation is visible rather than implied.
| Component quality | Unaided users only (vendor figure) | Population @ 30 % auto-catch | Population @ 40 % auto-catch | Population @ 50 % auto-catch |
|---|
4. The 30-interaction journey
Milestone steps (1, 5, 10, 20, 30) carry full narrative treatment as the run advances. Blocking defects are seeded at published rates and revealed live.
5. Live probabilistic readout
The general journey
0.00 %1 − (0.99)^0 = 0.00 %
The number the vendor publishes when they average their component checks: 99 % each, 73.97 % for the whole form.
This citizen's journey
0.00 %p = 0.0100, n = 0
Weighted for combined domain constraints.
6. Defect record
No defect has manifested yet. Run the simulation to reveal the first barrier the citizen meets — with its mechanic, obligation source, WCAG/ACT/FPC citation, first-person account, and an automated-scanner verdict.
7. Journey defect ledger
Every barrier this run has revealed, in order of occurrence, tagged by mechanic and obligation source. Note how few of them are walls — and how many are not conformance failures at all.
- Empty ledger
Non-WCAG systemic barriers
Barriers that stop citizens cold while violating no success criterion. They are the clearest demonstration that conformance and access are not the same measurement.
- Empty ledger
8. Why automated scanners report green
Deque's own published position, and the U.S. General Services Administration's testing guidance, both state that automated testing detects roughly 30–40 % of WCAG 2.2 A/AA success criteria (GSA's figure is closer to 30 %; Deque reports ~40 % of issues). The residual 60 %+ requires human judgment and assistive technology. The average vendor audit in the WebAIM Million corpus of the top one million home pages (2025) still finds 51 accessibility errors per home page, despite years of automated monitoring.
Every defect in this run's ledger is one a crawler cannot decide. The scanner tests the DOM at load. It does not test the journey through time.
9. Executive summary
Method notes, sources, and limits
What the mathematical model does and does not claim
- The product-of-reliabilities result — 1 − (1−p)ⁿ — follows directly from treating independent steps as a serial system. It is exact arithmetic, not a heuristic.
- Step independence is a modelling simplification for explanatory purposes. Real automated tests are strongly correlated: a widget library that ships one broken pattern breaks every instance of it. Correlation narrows the variance around the mean; it does not eliminate the expected loss of task completion.
- The recovery term. Because defects are not uniformly fatal, the live run separates two kinds: friction defects (which the citizen may work around, at cost) and deterministic blockers (which end the task). Only blockers stop the run. This prevents the simulator from overstating the loss and keeps the arithmetic honest.
- Ri weightings are illustrative. They express relative exposure by capability domain and should be calibrated with real task-completion data before being quoted as a forecast for any specific population.
- The 99 % baseline is a stipulation, generously granted for the sake of argument. Published government benchmarking for complex multi-step services sits far below it.
Standards, rules, and sources referenced in this artefact
- WCAG 2.2 — W3C Recommendation. Success Criteria cited here: 1.1.1 Non-text Content; 1.3.1 Info and Relationships; 1.3.2 Meaningful Sequence; 1.4.1 Use of Color; 2.1.1 Keyboard; 2.2.1 Timing Adjustable; 2.4.3 Focus Order; 2.4.4 Link Purpose (In Context); 2.4.6 Headings and Labels; 2.4.7 Focus Visible; 2.4.11 Focus Not Obscured (Minimum); 2.5.1 Pointer Gestures; 2.5.7 Dragging Movements; 2.5.8 Target Size (Minimum); 3.2.2 On Input; 3.3.1 Error Identification; 3.3.2 Labels or Instructions; 3.3.3 Error Suggestion; 3.3.7 Redundant Entry; 4.1.2 Name, Role, Value; 4.1.3 Status Messages.
- W3C ACT Rules — c487ae Link has non-empty accessible name; 97a4e1 Button has non-empty accessible name; e086e5 Form field has non-empty accessible name; cc0f0a Form field label is descriptive (proposed); 2779a5 HTML page has non-empty title; c4a8a4 HTML page title is descriptive; d0f69e Table header cell has assigned cells (proposed); 80af7b Focusable element has no keyboard trap (proposed); bc4a75 ARIA required owned elements; ff89c9 ARIA required context role; b4f0c3 Meta viewport allows for zoom. Note: WCAG 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum) and 2.4.11 have no ACT rule yet — a structural gap in the standardised test surface.
- Section 508 / EN 301 549 Functional Performance Criteria (the Chapter 3 / Clause 4 statement set): 302.1 / 4.2.1 Without Vision; 302.2 / 4.2.2 With Limited Vision; 302.3 / 4.2.3 Without Perception of Colour; 302.4 / 4.2.4 Without Hearing; 302.5 / 4.2.5 With Limited Hearing; 302.6 / 4.2.6 Without Speech; 302.7 / 4.2.7 With Limited Manipulation; 302.8 / 4.2.8 With Limited Reach and Strength; 302.9 / 4.2.9 With Limited Language, Cognitive, and Learning Abilities.
- Microsoft Inclusive Design — the Persona Spectrum: Permanent, Temporary, Situational, applied across Vision, Motor/Touch, Cognition, and Hearing/Speech.
- Automated coverage evidence — Deque Systems (~40 % of issues detectable by automation); GSA Section 508 testing guidance (~30 % of success criteria); WebAIM Million 2025 (51 errors per home page average) and 2026 (56.1 errors per page; 95.9 % of pages with detectable WCAG 2 failures).
- Journey mapping practice — Government of Canada CSPS Journey Map job aid; UK GDS design notes on user journey mapping; Ontario Digital Service journey mapping guide.
Scope and disclaimer
This artefact is a teaching and advocacy model, not a conformance claim, not a legal opinion, and not a substitute for manual testing with assistive technology. It is designed to be quoted carefully: quote the arithmetic and the standards citations, not the illustrative weightings, which require calibration against real completion data.