Methodology
Where the lawsuit-risk score comes from.
Every finding in your scan report carries a score from 0 to 100. This page explains exactly how that score is calculated, which sources it draws on, and — critically — what it cannot tell you.
The score in one paragraph
A prioritisation heuristic, not a legal opinion.
Derived from cross-referencing three bodies of data: (1) 2025-2026 lawsuit datasets, (2) demand-letter frequency analysis, (3) the FTC's April 2025 AccessiBe order. Updated when new annual reports or significant litigation are published.
| Score band | Meaning |
|---|---|
| 90 – 100 | Routinely cited verbatim in demand letters |
| 70 – 89 | Appears in > 40% of consumer-facing complaints |
| 40 – 69 | Cited but not central to most complaints |
| 0 – 39 | Technical rules rarely surfaced in litigation |
Top 10 trigger rules
The axe-core rules we prioritise — and why.
Drawn from our internal risk-ranking module, updated with each annual data release.
| Rule ID | Score | WCAG SC | Plain-English name | Citation reason |
|---|---|---|---|---|
| image-alt | 95 | 1.1.1 | Missing alt text on images | Single most-cited violation in 2025-2026 ADA web demand letters |
| link-name | 90 | 2.4.4 | Ambiguous or empty link text | Second-most-cited barrier in screen-reader plaintiff reports |
| button-name | 88 | 4.1.2 | Unlabeled button (checkout, cart, form submit) | Repeatedly cited in ecommerce-specific demand letters |
| color-contrast | 80 | 1.4.3 | Insufficient contrast ratio between text and background | Most-flagged automated finding in plaintiff-side expert reports |
| label | 78 | 1.3.1 / 4.1.2 | Form field missing programmatic label | Cited in account-creation and checkout barrier complaints |
| document-title | 60 | 2.4.2 | Missing or empty page title | Cited in template-style demand letters; less central than visual violations |
| html-has-lang | 55 | 3.1.1 | HTML element missing lang attribute | Occasional citation; AT mispronunciation argument |
| page-has-heading-one | 50 | 1.3.1 | Page lacks an h1 heading | Appears in template demand letters; rarely the primary claim |
| region | 45 | 1.3.6 | Content not contained in landmark region | Mentioned in complaints but rarely the central barrier |
| landmark-one-main | 45 | 1.3.1 | Page lacks a single main landmark | Ancillary citation; structural navigation pattern |
The 25–57% gap
What automated scans cannot detect.
Multiple peer-reviewed studies, Deque's documentation, and the WebAIM Million Report consistently find that automated tools detect 25–57% of WCAG violations on a given page. The remaining failures require human judgment.
Keyboard navigation completeness
Can every interactive element be reached, operated, and exited using only a keyboard? Automated tools detect missing tabindex but cannot verify the full nav flow.
Screen-reader output quality
Does VoiceOver or NVDA read the page in a logical, understandable order? DOM analysis can flag missing roles but cannot test the audio experience.
Meaningful alternative text
Tools detect missing alt (scored 95 above) but cannot judge whether present alt is accurate. 'Image of a red shoe' is technically present; 'Nike Air Max 90 in University Red' is meaningful.
Cognitive load and plain language
WCAG 3.2 guidance on understandable content has no automated signal.
Custom interactive widgets
Carousels, modals, date pickers, and autocomplete widgets require manual keyboard and AT testing to verify ARIA live region behavior.
Assistive-technology user testing
Real users of screen readers, switch controls, voice control, and magnifiers reveal barriers no static analysis can predict.
Manual review checklist (included in every Defense PDF)
- 01Keyboard navigation — all interactive elements reachable and operable without a mouse
- 02Focus indicator — visible focus ring on all focused elements
- 03Screen reader testing — NVDA/VoiceOver reads all content in logical order
- 04Video captions — all pre-recorded video has accurate captions
- 05Audio descriptions — all pre-recorded video has audio description or text alternative
- 06Timeout warnings — sessions that expire give at least 20 seconds warning
- 07Error identification — form errors identify the field and describe the issue in text
- 08Consistent navigation — nav appears in the same order across pages
- 09On focus / on input — no context change triggered solely by focus or input
- 10Language of parts — inline foreign-language text uses lang attribute
Detailed formulas
How each score is computed — exact formulas.
Below are the actual computations behind every metric surfaced in the app and the Defense PDF. No formula is changed when you scan — this page only documents what already runs.
Accessibility score (0–100)
Unified headline score. A weighted ratio of axe-core passes vs open failures — user-status-aware: marking an issue done increases the score without a rescan.
weighted_passes = nodes_passed_total × 3 weighted_failures = Σ count_open(impact) × weight(impact) where weight: critical=10 / serious=5 / moderate=2 / minor=1 accessibility_score = round(100 × weighted_passes / (weighted_passes + weighted_failures)) Returns null if denominator = 0 (degenerate scan).- Only open issues (status = open) contribute to weighted_failures. Issues marked done or ignored are excluded — triage directly improves the score.
- nodes_passed_total is the cumulative count of DOM nodes that passed an axe rule, captured at scan time.
- The passes coefficient (×3) approximates the average severity weight of a passing test. Calibrated empirically on reference scans.
- Single exposed score. Scans created before the deployment show null until the next recompute (triggered by a manual issue triage).
Legal coverage %
Engine availability ratio — the share of a legal reference for which an automated rule exists. NOT the share of your site that passes.
legal_coverage_pct = count(rules_with_engine_coverage) / count(rules_in_reference) × 100- A high coverage % means the engine can test many rules of that standard — it does not mean your site is compliant on those rules.
- Coverage is reported per standard (WCAG 2.2 AA, RGAA 4.1, Section 508, EN 301 549) and aggregated weighted by the count of testable rules in each.
- Manual-only criteria (e.g., WCAG 1.2.2 Captions accuracy) are by definition NOT in coverage.
WCAG principle subscores (Perceivable / Operable / Understandable / Robust)
Four per-principle compliance rates derived from the issues found, mapped via WCAG SC → principle.
subscore(principle) = 1 − (failed_issues_in_principle / testable_rules_in_principle) where failed_issues excludes manual_required and needs_review- Issues tagged with multiple WCAG principles (e.g. an issue mapped to both 1.3.1 Perceivable and 4.1.2 Robust) increment each principle independently. The four subscores can therefore sum to more than 100% of the total issue count — by design.
- manual_required and needs_review outcomes are excluded from the failed count to avoid penalising criteria the engine cannot decide.
- Used for diagnostic radar charts only — not for the headline conformity score.
Lawsuit risk — Litigation likelihood (0-100, per issue)
Per-issue likelihood score blending impact × WCAG multiplier × jurisprudence boost when historical lawsuit data exists for that rule.
base = impact_base[issue.impact] × max(wcag_multiplier[tag] for tag in issue.wcag_tags) if rule_id in RULE_JURISPRUDENCE_TABLE: settlements_boost = min(SETTLEMENTS_BOOST_CAP, settlements_count / DIVISOR) median_boost = min(MEDIAN_BOOST_CAP, median_usd / DIVISOR) score = round(base × (1 + settlements_boost + median_boost)) else: score = base score = clamp(score, 0, 100)- Shown in the app and in the Defense PDF (per-issue priority column).
- Not a USD estimate — it is a relative likelihood ranking used to triage which issues to fix first.
- Rules absent from the jurisprudence table fall back to legacy impact × WCAG only.
Source: RULE_JURISPRUDENCE_TABLE sourced from UsableNet ADA Web Lawsuit Trends 2025 + Seyfarth ADA Title III FY2024.
Lawsuit risk — USD exposure estimate (Defense PDF only)
Estimated monetary exposure. Surfaced ONLY in the Defense PDF, never as a standalone number in the dashboard, to avoid being read as a prediction.
raw = sum_issues( litigation_weight(rule) × impact_multiplier × volume_factor(nodes) ) exposure_usd = raw × BASE_SETTLEMENT_USD × jurisdiction_multiplier exposure_usd = clamp(exposure_usd, LAWSUIT_RISK_MIN_USD, LAWSUIT_RISK_MAX_USD) # BASE_SETTLEMENT_USD = $55,000 # jurisdiction_multiplier defaults to 1.0 (US) # Caps applied: floor $20k (single-scan), ceiling $150k (single-scan) # Hard cap $500k applies only to optimistic/pessimistic scenario bands- BASE_SETTLEMENT_USD ($55k) = midpoint of the $25k-$75k median range reported by Seyfarth ADA Title III Year-End FY2024 for pre-litigation digital ADA settlements.
- Caps clamp the result inside the statistical band observed in 2024-2025 datasets ($20k-$150k floor/ceiling on single-scan estimate; $500k hard cap on scenario bands). Outliers are NOT extrapolated.
- The jurisdiction_multiplier is 1.0 (US) by default. Non-US jurisdictions are not yet calibrated — treat as US-only.
- This number is indicative, not a legal opinion. Re-verify annually when the next Seyfarth report ships.
Source: Seyfarth Shaw LLP — ADA Title III Federal Lawsuits Year-End Report FY2024.
Quick wins — gain_points
Triage list of issues with high impact and low effort. The `gain_points` value is a count of templating-unit fixes, NOT a delta in the score.
gain_points = number_of_unique_template_locations_to_fix- Do NOT interpret gain_points as 'points added to the score if I fix this'. It is a count of distinct template/component patches.
- A single template fix can resolve dozens of page-level instances (e.g., one image-alt fix in a product card component).
Fix effort (hours per issue)
Indicative time-to-fix estimate per axe-core rule, used to rank quick wins. Internal estimates based on historical fix data.
effort = FIX_EFFORT_HOURS.get(rule_id, FIX_EFFORT_HOURS_DEFAULT) # Range observed: 0.1h - 4h per rule. Default = 1.0h.- Estimates are PER UNIQUE TEMPLATE LOCATION, not per page-level occurrence.
- Effort estimates are calibration values from internal project history. They do not account for QA, deployment, or regression testing.
Viewport gap warning (desktop vs mobile)
Flags scans where the desktop and mobile density scores diverge significantly, suggesting responsive-only failures.
viewport_gap_warning = abs(desktop_score − mobile_score) > VIEWPORT_GAP_WARNING_THRESHOLD # VIEWPORT_GAP_WARNING_THRESHOLD = 15 (empirical project threshold)- Threshold of 15 points is empirical (project calibration). It is not a WCAG-derived value.
- When triggered, the report adds a viewport-specific recommendation block — but does not penalise the headline score.
Regression detection (vs previous scan)
Compares the current scan against the previous scan with matching legal references, surfacing rules that newly fail.
regression = (rule failed_delta ≥ DEFAULT_REGRESSION_MIN_FAILED_DELTA) # DEFAULT_REGRESSION_MIN_FAILED_DELTA = 1- A delta of 1 is intentionally aggressive — even one new failing node triggers the regression flag.
- The comparison is filtered by matching legal references between scans (issue #211 fix). A scan against a different referential will not regression-compare.
Multi-page consistency — amplification
When the same rule fails across multiple pages, the penalty contribution is amplified to reflect the recurring template defect.
penalty += SCORE_WEIGHT_SERIOUS × pages_affected # No cap currently — tracked for a future iteration.- An issue affecting 10 pages contributes 10× the SERIOUS weight, regardless of the issue's own impact level. Rationale: a recurring template failure is by nature serious.
- No upper cap on pages_affected yet — very large sites with widespread template defects can see the headline score saturate at 0.
Sources
Cite-grounded — public, dated, linkable.
- UsableNet ADA Web Lawsuit Trends 2026
annual industry report; source for 1,023 lawsuits-with-overlay stat and H1 2025 monthly defendant counts.
- TestParty ADA Lawsuit Trends 2025–2026
violation-type frequency across ecommerce defendant filings.
- FTC Final Order — AccessiBe (April 2025)
regulatory grounding for which failure types constitute material accessibility barriers.
- LFLegal — UserWay Class Action (February 2025)
magistrate ruling identifying overlay-specific legal exposure.
- LFLegal — AccessiBe Class Action (July 2024)
complaint allegations detail which failure types plaintiffs relied on.
- WCAGsafe — Shopify ADA Compliance 2026
Shopify-vertical breakdown of violation frequency.
- axe-core 4.11 ruleset (Deque Systems)
WCAG testing engine used by US 18F, Microsoft, Google, and thousands of accessibility programs.
Why this differs from a legal opinion
This is a heuristic, not legal advice.
The lawsuit-risk score prioritises which violations to fix first based on statistical frequency in litigation filings. It does not predict whether any particular site will be sued, what the outcome of any suit would be, or whether a given violation constitutes a legal violation of the Americans with Disabilities Act, Section 508, or any other law.
Whether a site is legally accessible under the ADA is a factual and legal determination that requires attorney review, manual accessibility testing, and often assistive-technology user testing. ScanAccess's scans and PDFs are tools for documenting good-faith compliance effort — they are not legal opinions and should not be presented as such.
Automated WCAG 2.2 AA scan via axe-core 4.11. Automated tools detect approximately 25–57% of accessibility violations. This is not a guarantee of legal compliance. It is evidence of a documented, recurring good-faith compliance effort.