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
| Severity | Per issue | Cap | Typical examples |
|---|---|---|---|
| Critical | −10 | −50 | Missing image alt on non-decorative content, no form labels, empty links on interactive targets |
| Serious | −5 | −30 | Insufficient colour contrast, missing lang on <html>, duplicate IDs |
| Moderate | −2 | −15 | Missing skip-nav link, heading levels skipped, table headers not associated |
| Minor | −0.5 | −5 | Redundant 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
Severity caps limit each category's contribution to the score. Different issue counts can therefore produce the same score. Review the issue list and affected workflows alongside the number.
Score colour
The dashboard and site cards colour-code the score so you can triage at a glance:
| Range | Colour | Rough reading |
|---|---|---|
| 80 – 100 | Green | Few or no automated violations. Still needs manual testing for full conformance. |
| 50 – 79 | Amber | Mixed. Some real barriers — prioritise critical and serious first. |
| 0 – 49 | Red | Significant 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. The score only reflects what automated rules can detect (see WCAG Coverage). A score of 100 does not mean "conformant" — it means no automated rule fired, which rules out the failure patterns those rules cover and nothing more. Thirty of the 55 active WCAG 2.2 A/AA criteria have no automated rule at all and never affect the score.
- Counts do not capture full user impact. Findings with the same severity receive the same scoring treatment even when their effect on a user's task differs. Review affected elements, key workflows, and manual checks. Neither the score nor the selected-barriers card predicts legal 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.