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 bandMeaning
90 – 100Routinely cited verbatim in demand letters
70 – 89Appears in > 40% of consumer-facing complaints
40 – 69Cited but not central to most complaints
0 – 39Technical 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 IDScoreWCAG SCPlain-English nameCitation reason
image-alt951.1.1Missing alt text on imagesSingle most-cited violation in 2025-2026 ADA web demand letters
link-name902.4.4Ambiguous or empty link textSecond-most-cited barrier in screen-reader plaintiff reports
button-name884.1.2Unlabeled button (checkout, cart, form submit)Repeatedly cited in ecommerce-specific demand letters
color-contrast801.4.3Insufficient contrast ratio between text and backgroundMost-flagged automated finding in plaintiff-side expert reports
label781.3.1 / 4.1.2Form field missing programmatic labelCited in account-creation and checkout barrier complaints
document-title602.4.2Missing or empty page titleCited in template-style demand letters; less central than visual violations
html-has-lang553.1.1HTML element missing lang attributeOccasional citation; AT mispronunciation argument
page-has-heading-one501.3.1Page lacks an h1 headingAppears in template demand letters; rarely the primary claim
region451.3.6Content not contained in landmark regionMentioned in complaints but rarely the central barrier
landmark-one-main451.3.1Page lacks a single main landmarkAncillary 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)

  1. 01Keyboard navigation — all interactive elements reachable and operable without a mouse
  2. 02Focus indicator — visible focus ring on all focused elements
  3. 03Screen reader testing — NVDA/VoiceOver reads all content in logical order
  4. 04Video captions — all pre-recorded video has accurate captions
  5. 05Audio descriptions — all pre-recorded video has audio description or text alternative
  6. 06Timeout warnings — sessions that expire give at least 20 seconds warning
  7. 07Error identification — form errors identify the field and describe the issue in text
  8. 08Consistent navigation — nav appears in the same order across pages
  9. 09On focus / on input — no context change triggered solely by focus or input
  10. 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).
  • 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.

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.

GitHub Action