Developer Accessibility Checklist
A comprehensive accessibility checklist organized by WCAG's four principles (Perceivable, Operable, Understandable, Robust). 68 items with links to relevant patterns and guides. Check off as you build — your progress is saved automatically.
Frequently asked questions
Does this checklist cover WCAG 2.2 AA?
Yes — every item maps to one or more WCAG 2.2 success criteria, all at Level AA or below. Many items also cover Level AAA practices that are easy wins. The four groups follow the four POUR principles (Perceivable, Operable, Understandable, Robust) so coverage is structured the same way the WCAG spec is.
How long does it take to run through the full checklist?
Plan ~2-4 hours for a thorough single-page audit by a developer who is fluent with the codebase. Larger apps take a day or more. Run it again at every major release. Most teams use a subset as a pre-merge gate (the keyboard + screen-reader + forms items) and reserve the full pass for release milestones.
What's the difference between this and the testing checklist?
This Developer checklist is for items you can verify by reading or running code — markup, semantics, ARIA, color contrast, focus management. The Testing checklist is the QA-facing version, focused on what to do with automated tools, keyboard testing, and real screen readers. They're complementary — most teams use both.
Is this maintained?
Yes — A11yPath is actively maintained. Items are updated when WCAG 2.2 is amended or when new patterns / common pitfalls emerge. The page is data-driven, so updates roll out cleanly across the schema markup, item count, and progress tracking.
What if I'm building with React, Vue, or another framework?
The items are framework-agnostic — they describe what the rendered DOM should look like, not how you got there. Most framework accessibility pitfalls (focus management on route change, ARIA state syncing, portal-rendered modals losing focus traps) are covered under the Operable and Robust sections. Per-framework guides are on the roadmap.
Can I export the checklist?
Use the browser's print dialog (Cmd/Ctrl-P) — the checklist is print-styled. Checkboxes render with borders and your progress is preserved. The page is plain semantic HTML, so PDFs from any print-to-PDF tool work cleanly too.
Is my progress saved if I close the tab?
Yes — checked items are stored in localStorage and restored on next visit, scoped to this checklist's slug. Use the Reset All button at the bottom to clear progress. Progress is per-browser, not synced across devices.
Should I use this before or after development?
Both. Before: scan the checklist when planning new components so you design for keyboard + screen reader from the start. After: run through it as a pre-launch gate. The Pre-launch checklist is a tighter subset focused on must-fix-before-ship items.
What automated tools should I use alongside this?
Automated tools catch ~30% of accessibility issues. Pair this checklist with axe DevTools, Lighthouse, or Pa11y for color contrast, missing alt attributes, and broken ARIA references. They won't catch keyboard traps, focus management, or whether your ARIA roles are semantically meaningful — that's why the manual checklist exists.
What about cognitive accessibility?
WCAG 2.2 added several items under Understandable that target cognitive accessibility — consistent navigation, error prevention, autocomplete, redundant entry, and accessible authentication. The Understandable section covers these. Cognitive accessibility is also a major focus of WCAG 3.0, which is still in draft.