Scorecards
Every shipped scorecard. Each version pins each stable check id to a specific implementation. Older versions stay reproducible forever so historical scores can be trended consistently.
How scorecards work
A scorecard is a frozen manifest pinning each stable check id to an implementation version. Once shipped, a scorecard never changes: when a check’s behaviour evolves, a new scorecard is published that points at the new implementation version while older scorecards keep pointing at the old one.
This means historical audits stay reproducible: if you measured your site against v0.2.0 last month, re-running v0.2.0 today gives the same score even after the engine ships new check versions.
Scoring methodology
The scoring algorithm — how each check’s pass/fail/na status turns
into a single 0–100 number — is part of every scorecard’s contract.
Scorecards pin a scoringMethodology alongside their check set so
the algorithm can evolve without retroactively changing the scores
of older scorecards. A consumer pinned to v0.2.0 keeps getting the
v0.2.0 algorithm forever, even after later scorecards adopt newer ones.
Each scorecard pins exactly one algorithm. v0.2.0 ships
flat-pool-v1; the v0.3.0 draft
introduces per-check-mean-v1
to fix a page-count weighting issue in flat-pool. See
every shipped algorithm for the formulas and
worked examples. Methodology changes between scorecard versions are
recorded on each draft’s changes page like any other contribution.
Shipped versions
Draft
The next planned scorecard, in flight. Subject to change. PRs proposing new checks or revisions land here — see CONTRIBUTING.md .
Pinning a scorecard
Use --scorecard <version> on the CLI or the dropdown
in the extension popup to evaluate against a specific scorecard. The
default is always the latest version.