Checklists

Run this before approving any non-trivial pull request — it works for a five-line fix and a five-hundred-line feature alike, just skim faster on the small ones.

Work through this in the final days before launch, then again right after the DNS switch — some checks only make sense once the site is actually live.

Use this for a periodic health check on an existing site, or as the first pass when you inherit one you didn't build.

Run this against a page or component before shipping it, using an actual keyboard and screen reader alongside automated tools — automated checks alone catch a minority of real accessibility issues.

Work through this before a major release, or periodically on an existing app — it's written for the engineer shipping the code, not a compliance audit.

Follow this from the moment something looks wrong through the retro afterward — the earlier sections matter most in the first ten minutes, when clear steps beat improvisation.

Work through this on your own branch after you think you're done, before you open the pull request or ask anyone to look at it.

Run this against a real page on a throttled connection, ideally alongside field data you already have, before chasing a lab score that may not reflect actual visitors.