// 10 checklists · interactive · progress saved locally
Accessibility Checklists
Ten free, interactive accessibility checklists covering WCAG 2.2 compliance, developer self-audit, QA testing, React, single-page apps, mobile, forms, content, design review, and pre-launch. Every item maps to one or more WCAG 2.2 success criteria. Check off items as you go — progress is saved automatically in your browser. Print-friendly for pinning to your desk or using during code review.
// what is this
What is an accessibility checklist?
An accessibility checklist is a structured list of verifiable items that a website or application must satisfy to be usable by people with disabilities — keyboard-only users, screen reader users, users who need magnification, users with cognitive differences, and many more. Good checklists translate the WCAG (Web Content Accessibility Guidelines) specification into specific actions you take on your codebase or design.
The value of working from a checklist over an ad-hoc audit is completeness and reproducibility. Without a checklist, accessibility reviews tend to surface the issues the reviewer has been thinking about lately, while quietly missing entire categories (cognitive load, time limits, drag alternatives, animation preferences). Checklists also create the artifact that compliance audits, procurement reviews, and accessibility statements need to cite.
The right checklist depends on who's doing the work and when. A designer needs different items than a developer; a pre-launch sweep covers different ground than a per-PR code review. The next section helps you pick.
// choosing a checklist
Which checklist should I use?
By role
- Developers (any framework): start with the Developer Accessibility Checklist — 68 items organized by WCAG's four principles, covering everything you can verify from code.
- React developers: the React Accessibility Checklist adds the React-specific gotchas — route-change focus, ARIA state syncing,
useId, Portals, controlled-component forms. - SPA developers (any framework): the SPA Accessibility Checklist covers framework-agnostic single-page app concerns: routing, focus management, dynamic content, history.
- QA / testers: the Accessibility Testing Checklist is the workflow version — what to actually run, click, and listen for, including automated scanning with axe, Lighthouse, and Pa11y.
- Designers: the Design Review Accessibility Checklist covers what to catch before code starts — contrast, focus indicators, target sizes, motion, error states.
- Writers and content designers: the Content & Editorial Checklist covers plain language, headings, link text, alt text, inclusive language, and UX writing.
By workflow phase
- Design phase: Design Review.
- Build phase: Developer (or React / SPA for those stacks), plus Forms for any form-heavy feature.
- QA / acceptance: Accessibility Testing.
- Pre-launch / final sign-off: Pre-launch Accessibility Checklist — the consolidated last pass before shipping.
By compliance target
- WCAG 2.2 Level A & AA (the most common legal target): the WCAG 2.2 Compliance Checklist provides a one-to-one mapping of every Level A and AA success criterion to an actionable check — ideal for audit documentation and procurement responses.
- Mobile / app stores: the Mobile Accessibility Checklist adds touch-target, gesture, and mobile screen reader coverage on top of the standard web items.
Most teams pair two or three checklists — a role-based one for daily work, plus the WCAG 2.2 Compliance Checklist for audit paperwork, plus the Pre-launch Checklist as a release gate. All ten use the same progress-tracking infrastructure, so you can run several in parallel without state conflicts.
// browse all
All checklists
Sorted by most recently updated. Each card shows the item count, scope, and difficulty tags. Click any card to open the interactive checklist.
-
React Accessibility Checklist
React-specific accessibility issues most teams miss: route-change focus, ARIA state syncing, useId, Portals + dialogs, controlled-component forms, and React Testing Library queries. 36 items.
-
Pre-launch Accessibility Checklist
The final accessibility check before shipping. 30 items across 7 groups covering keyboard, screen readers, forms, color, errors, and pre-launch edge cases.
-
Content & Editorial Accessibility Checklist
For writers, editors, and content designers. 25 items covering plain language, headings, link text, alt text, inclusive language, and UX writing.
-
SPA Accessibility Checklist
24-item checklist for single page application accessibility covering route changes, focus management, dynamic content, error handling, and testing.
-
WCAG 2.2 Compliance Checklist
Every WCAG 2.2 Level A and AA success criterion mapped to an actionable check. 54 items organized by the four principles.
-
Forms Accessibility Checklist
24-item checklist covering labels, grouping, validation, error handling, input types, and keyboard interaction for accessible forms.
-
Mobile Accessibility Checklist
24-item checklist for mobile web covering touch targets, gestures, screen readers, responsive layout, and motion/media concerns.
-
Design Review Accessibility Checklist
Accessibility checks for visual and interaction design. Use during design review or handoff to catch issues before they reach code. 24 items across 5 categories.
-
Developer Accessibility Checklist
A comprehensive checklist organized by WCAG's four principles (Perceivable, Operable, Understandable, Robust). 26 items covering everything from alt text to ARIA roles.
-
Accessibility Testing Checklist
A 46-point step-by-step QA testing workflow: automated scanning (axe, Lighthouse, Pa11y), keyboard testing, screen reader testing, visual/responsive checks, and cognitive content audits.
// frequently asked
Frequently asked questions
What is an accessibility checklist?
An accessibility checklist is a structured list of verifiable items that a website, application, or document must satisfy to be usable by people with disabilities. The best checklists map each item to a specific WCAG (Web Content Accessibility Guidelines) success criterion so you can prove compliance, and group items by the role doing the work (developer, designer, content writer, QA tester) or by the workflow phase (design review, build, test, pre-launch).
How are these checklists different from the WCAG specification?
WCAG is the specification — the formal definition of accessibility success criteria, written for normative reference. These checklists translate WCAG into specific, verifiable actions you take on your codebase or design. WCAG 2.1.1 Keyboard says "all functionality must be operable from a keyboard"; the checklist version says "Tab through the entire page and confirm every interactive element receives focus." Same intent, different unit of work. See our WCAG 2.2 overview for the full mapping.
Are these checklists WCAG 2.2 compliant?
Yes. Every item on every checklist maps to one or more WCAG 2.2 success criteria at Level A or Level AA (with some Level AAA items called out as easy wins). The dedicated WCAG 2.2 Compliance Checklist provides a one-to-one mapping of every Level A and AA criterion in the spec to an actionable check — useful for audit documentation and procurement responses. The role-based checklists (developer, design, content) cover the same criteria, organized around the work each role actually does.
Are these accessibility checklists free?
Yes. Every checklist is free to use — no signup, no paywall, no tracking beyond Cloudflare's privacy-preserving analytics. You can use them on commercial projects, share them with your team, link to them in documentation, or print them for your own reference. The site is open source on GitHub if you want to inspect the data or suggest changes.
Can I print these accessibility checklists?
Yes — each checklist has a Print button (inline with the progress bar at the top) that opens a print-formatted version with navigation, header, and footer hidden, larger checkboxes, and a clean grouped layout suited to paper or PDF. If you've already checked items in the browser, the print version preserves those checks (with a line-through and filled checkbox) so you can print your current progress as a snapshot.
How is checklist progress saved?
Progress is saved automatically in your browser's localStorage — no account, no server. Each checklist has its own storage key, so progress on the Developer checklist won't affect progress on the Mobile or React checklists. The data lives only on your device; closing or reopening the page keeps your checks. Use the Reset button at the bottom of any checklist to clear its progress.