Accessibility Score

Every scanned site gets a single 0–100 score that summarises its automated accessibility posture. The formula weights findings by severity and caps each severity bucket so no single category can drive the score to zero on its own.

The formula

score = 100 − (critical × 10)  capped at −50
              − (serious  ×  5)  capped at −30
              − (moderate ×  2)  capped at −15
              − (minor    × 0.5) capped at  −5

final score is clamped to 0 and rounded to the nearest integer

Only deterministic violations are counted. Advisory items (HTMLCS notices, AI pattern checks) never affect the number — they live on the site detail page with a Manual review label but do not enter the score, VPAT, or any public surface.

Severity weights and caps

SeverityPer issueCapTypical examples
Critical−10−50Missing image alt on non-decorative content, no form labels, empty links on interactive targets
Serious−5−30Insufficient colour contrast, missing lang on <html>, duplicate IDs
Moderate−2−15Missing skip-nav link, heading levels skipped, table headers not associated
Minor−0.5−5Redundant ARIA roles, tabindex greater than 0

Worked example

A scan returns 3 critical, 5 serious, 2 moderate, and 4 minor findings:

critical:  3 × 10  = 30   (not capped — under 50)
serious:   5 ×  5  = 25   (not capped — under 30)
moderate:  2 ×  2  =  4   (not capped — under 15)
minor:     4 × 0.5 =  2   (not capped — under  5)

deductions = 30 + 25 + 4 + 2 = 61
score      = 100 − 61 = 39

If the same site had 20 critical findings instead of 3, the critical deduction would hit its cap at −50 (rather than −200), so the score would still reflect the other severities rather than flatline at zero.

Why caps exist

Caps stop a single severity from dominating the number. A site with 50 minor findings and nothing else should still look basically fine — it gets −5 for minors, score ≈ 95. A site with 10 critical findings should read as serious, but shouldn't be indistinguishable from a site with 100 critical findings — both hit the −50 cap but the second is worse to look at (more detail rows, higher litigation risk). The score is a summary; the issue list carries the nuance.

Score colour

The dashboard and site cards colour-code the score so you can triage at a glance:

RangeColourRough reading
80 – 100GreenFew or no automated violations. Still needs manual testing for full conformance.
50 – 79AmberMixed. Some real barriers — prioritise critical and serious first.
0 – 49RedSignificant barriers present. Remediation should be treated as urgent.

Score tracking over time

Every scan persists its score and severity counts. The site detail's Scans tab has a trend chart covering the last ten completed scans, so you can watch progress across a remediation sprint or spot a deployment that introduced regressions. Per-site scores also appear in the dashboard table so multi-site orgs can scan score health at a glance without drilling into each one.

Limitations

  • Coverage ceiling. Automated scanning catches roughly 57–70% of WCAG 2.2 AA issues (see WCAG Coverage). A score of 100 does notmean “fully conformant” — it means no automated rule fired. Manual testing is still needed for the remaining 30–43%.
  • Count-based, not impact-based.A missing alt on a hero image and a missing alt on a decorative graphic both count as one critical. The score is a useful dashboard, not a risk-weighted priority list — the site detail page's Litigation Risk card fills that gap for lawsuit exposure.
  • Sampling. The score reflects only the pages the scanner reached. Large sites may be sampled; the site detail page shows exactly which pages were included.
  • Point-in-time. Dynamic content, A/B-tested variants, and user-generated content can change between scans. Use the score to track trends, not as a single authoritative measurement.

Use the score to track direction, catch regressions, and orient conversations with stakeholders — not as a certification. Combine it with manual testing and, where possible, sessions with users who rely on assistive technology.