WCAG Testing Checklist for Developers and QA
A practical WCAG testing checklist for semantics, forms, keyboard access, focus, contrast, ARIA, errors, and dynamic content.
Summary
- A WCAG checklist should be actionable, not only a list of success criteria numbers.
- Development and QA should check semantics, names, keyboard access, focus, errors, and contrast first.
What this checklist is for
This WCAG testing checklist is not a formal audit report and should not be used to claim full AA conformance. It is a practical way for product, design, QA, and engineering teams to catch common issues before release.
A useful checklist should be executable, not only a list of success criteria numbers. Start with main task pages, then move repeated findings back into components, content rules, and acceptance criteria.
Structure and names
Start by confirming that the page can be understood. Screen reader users, keyboard users, and search engines all depend on structure. These issues are often cheap to fix but important for navigation and comprehension.
- Each page has a clear and unique page title.
- Heading levels reflect content structure, not only visual size.
- Major regions use reasonable landmarks such as header, nav, main, and footer.
- Important buttons, links, form fields, and icon buttons have clear accessible names.
- Alt text matches the image purpose; decorative images do not add noise.
Keyboard, focus, and interaction states
Keyboard testing should use real tasks. It is not enough to confirm that elements receive Tab focus; users also need to operate controls, understand state changes, and leave the current component when needed.
- All interactive controls can be reached and operated with a keyboard.
- Tab order follows the visual and task logic.
- Focus indicators are visible and not removed or hidden by styling.
- Dialogs, menus, accordions, tabs, and similar components manage focus reasonably.
- Expanded, collapsed, selected, error, and loaded states can be understood.
Forms, errors, and task completion
Form issues often affect conversion, applications, payment, and support flows directly. Test by submitting invalid data and confirming that users can identify what failed, why it failed, and how to fix it.
- Each field has a label, necessary instructions, and format hints.
- Errors are not conveyed by color alone.
- Errors are associated with fields, and focus or summaries help users return to the problem.
- Success, failure, and loading states after submission are clear.
- CAPTCHA, verification, or authentication flows do not block some users from completing the task.
Contrast, zoom, and real screens
Contrast review is not only about brand colors. Before release, check text, links, errors, focus, disabled states, icons, borders, and dark or light backgrounds in real screen states.
Also confirm that content does not overlap, disappear, or become inoperable when zoom, narrow viewports, text spacing, or user system settings change.
Related pages
- Accesserty DevCheck
Run browser-based checks on local builds, staging pages, authenticated screens, and interactive states.
- Web accessibility checker
Check real pages, authenticated states, and interactive states before release.
- WCAG compliance tool
Review WCAG A/AA issue clues, severity, affected elements, and remediation hints.
- Accessibility testing guides
Browse guides by practical task: public signals, pre-release checks, post-launch maintenance, and standards limits.
- WCAG glossary page
- ARIA glossary page
- Focus path review guide
- Target size glossary page
- Accessible authentication glossary page