What This Template Is For
Accessibility testing often gets treated as a box-checking exercise that happens right before launch. By then, the cost of fixing issues is 10x higher than catching them during discovery or design. This template gives you a structured way to plan, execute, and track accessibility testing across every stage of product development.
The template covers the four WCAG 2.1 principles: Perceivable, Operable, Understandable, and Robust. Each principle maps to specific test cases with pass/fail criteria, severity ratings, and a remediation tracker so issues do not get filed and forgotten. You can use it for manual testing, automated tool audits, or assistive technology testing with screen readers.
Pair this template with the Product Discovery Handbook when you are validating that your product works for all users, not just the majority. If you are building user personas, the User Persona Template should include accessibility needs for each segment. The usability testing glossary entry covers testing fundamentals, and the Heuristic Evaluation Template provides a complementary lens for evaluating UX quality beyond accessibility.
When to Use This Template
- During discovery. Audit competitor products for accessibility gaps you can differentiate on.
- Before design handoff. Verify that wireframes and prototypes meet contrast, spacing, and interaction requirements.
- During development. Run automated accessibility scans (axe, Lighthouse) against staging builds.
- Before launch. Conduct manual screen reader testing and keyboard navigation audits.
- After customer complaints. Investigate specific accessibility issues reported by users with disabilities.
- Quarterly audits. Schedule recurring accessibility reviews as your product surface area grows.
How to Use This Template
- Define scope. Identify which flows, pages, or components you are testing. Do not try to audit everything at once. Start with your highest-traffic flows.
- Run automated scans first. Tools like axe DevTools, Lighthouse, and WAVE catch the low-hanging issues (missing alt text, contrast failures, missing labels). Record findings in the audit grid.
- Conduct manual keyboard testing. Tab through every interactive element. Verify focus order, focus visibility, and that all functionality is accessible without a mouse.
- Test with assistive technology. Use VoiceOver (Mac), NVDA (Windows), or TalkBack (Android) to navigate your flows. Record where the experience breaks or becomes confusing.
- Score and prioritize. Rate each issue by severity (Critical, Major, Minor) and assign owners with deadlines. Critical issues block launch. Major issues ship with a fix timeline. Minor issues go to the backlog.
The Template
Part 1: Test Plan
Product / Feature: [Name of the product or feature being tested]
Testing scope:
- ☐ Flow 1: [e.g., Sign-up and onboarding]
- ☐ Flow 2: [e.g., Dashboard navigation]
- ☐ Flow 3: [e.g., Settings and account management]
- ☐ Flow 4: [e.g., Core workflow (create, edit, delete)]
WCAG target level: ☐ A ☐ AA ☐ AAA
Testing methods:
- ☐ Automated scan (axe / Lighthouse / WAVE)
- ☐ Manual keyboard navigation
- ☐ Screen reader testing (VoiceOver / NVDA / TalkBack)
- ☐ Color contrast analysis
- ☐ Zoom and text scaling (200% minimum)
Assistive technologies tested:
| Technology | Version | Browser | Tester |
|---|---|---|---|
| [e.g., VoiceOver] | [e.g., macOS 15] | [e.g., Safari 18] | [Name] |
| [e.g., NVDA] | [e.g., 2025.1] | [e.g., Chrome 130] | [Name] |
Part 2: WCAG Audit Grid
Perceivable
| Criterion | Description | Pass/Fail | Severity | Notes |
|---|---|---|---|---|
| 1.1.1 Non-text Content | All images have meaningful alt text | ☐ | ☐ | |
| 1.3.1 Info and Relationships | Headings, lists, and tables are semantically correct | ☐ | ☐ | |
| 1.3.2 Meaningful Sequence | Reading order makes sense when CSS is disabled | ☐ | ☐ | |
| 1.4.1 Use of Color | Color is not the only way information is conveyed | ☐ | ☐ | |
| 1.4.3 Contrast (Minimum) | Text contrast ratio meets 4.5:1 (normal) or 3:1 (large) | ☐ | ☐ | |
| 1.4.4 Resize Text | Text can be resized to 200% without loss of function | ☐ | ☐ | |
| 1.4.11 Non-text Contrast | UI components and graphics meet 3:1 contrast | ☐ | ☐ |
Operable
| Criterion | Description | Pass/Fail | Severity | Notes |
|---|---|---|---|---|
| 2.1.1 Keyboard | All functionality is keyboard accessible | ☐ | ☐ | |
| 2.1.2 No Keyboard Trap | Focus can move freely. No element traps keyboard focus | ☐ | ☐ | |
| 2.4.1 Bypass Blocks | Skip navigation link is present and functional | ☐ | ☐ | |
| 2.4.3 Focus Order | Tab order follows logical reading sequence | ☐ | ☐ | |
| 2.4.6 Headings and Labels | Headings and labels describe their content | ☐ | ☐ | |
| 2.4.7 Focus Visible | Keyboard focus indicator is clearly visible | ☐ | ☐ |
Understandable
| Criterion | Description | Pass/Fail | Severity | Notes |
|---|---|---|---|---|
| 3.1.1 Language of Page | Page language is declared in HTML | ☐ | ☐ | |
| 3.2.1 On Focus | No unexpected context changes on focus | ☐ | ☐ | |
| 3.3.1 Error Identification | Errors are clearly described in text | ☐ | ☐ | |
| 3.3.2 Labels or Instructions | Form inputs have clear labels or instructions | ☐ | ☐ |
Robust
| Criterion | Description | Pass/Fail | Severity | Notes |
|---|---|---|---|---|
| 4.1.1 Parsing | HTML has no major parsing errors | ☐ | ☐ | |
| 4.1.2 Name, Role, Value | Custom controls have correct ARIA roles and states | ☐ | ☐ | |
| 4.1.3 Status Messages | Status updates are announced to screen readers | ☐ | ☐ |
Part 3: Issue Tracker
| ID | Criterion | Page/Component | Description | Severity | Owner | Deadline | Status |
|---|---|---|---|---|---|---|---|
| A-001 | [e.g., 1.4.3] | [e.g., Login form] | [What is broken] | [Critical/Major/Minor] | [Name] | [Date] | [Open/In Progress/Fixed] |
| A-002 | |||||||
| A-003 |
Severity definitions:
- Critical. Prevents users with disabilities from completing core tasks. Blocks launch.
- Major. Significantly degrades the experience but a workaround exists. Fix within 2 sprints.
- Minor. Cosmetic or low-impact issue. Schedule for backlog.
Part 4: Summary and Sign-off
Total issues found: [Number]
Critical: [Number] | Major: [Number] | Minor: [Number]
Overall assessment: ☐ Pass ☐ Conditional pass (no Critical, Major has fix timeline) ☐ Fail
Tested by: [Name, Date]
Reviewed by: [Name, Date]
Filled Example: SaaS Onboarding Flow
Part 1: Test Plan
Product / Feature: Acme Project Management. Onboarding flow (sign-up through first project creation).
Testing scope:
- ☑ Flow 1: Registration form and email verification
- ☑ Flow 2: Onboarding wizard (4 steps)
- ☑ Flow 3: First project creation and team invite
- ☑ Flow 4: Dashboard initial state
WCAG target level: ☑ AA
Testing methods:
- ☑ Automated scan (axe DevTools)
- ☑ Manual keyboard navigation
- ☑ Screen reader testing (VoiceOver)
- ☑ Color contrast analysis
- ☐ Zoom and text scaling (200% minimum)
Assistive technologies tested:
| Technology | Version | Browser | Tester |
|---|---|---|---|
| VoiceOver | macOS 15.2 | Safari 18.3 | Sarah Chen |
| axe DevTools | 4.9 | Chrome 130 | Marcus Rivera |
Part 2: WCAG Audit Grid (Selected Findings)
Perceivable
| Criterion | Description | Pass/Fail | Severity | Notes |
|---|---|---|---|---|
| 1.1.1 Non-text Content | All images have meaningful alt text | Fail | Major | Onboarding illustrations have empty alt="" but convey information |
| 1.4.3 Contrast (Minimum) | Text contrast ratio meets 4.5:1 | Fail | Critical | "Skip" link on wizard is 2.8:1 contrast (light gray on white) |
| 1.4.11 Non-text Contrast | UI components meet 3:1 contrast | Pass | - | All buttons and inputs meet threshold |
Operable
| Criterion | Description | Pass/Fail | Severity | Notes |
|---|---|---|---|---|
| 2.1.1 Keyboard | All functionality is keyboard accessible | Fail | Critical | "Choose template" cards cannot be selected via keyboard |
| 2.4.3 Focus Order | Tab order follows logical sequence | Fail | Major | Focus jumps from step 2 header to step 4 button, skipping form fields |
| 2.4.7 Focus Visible | Keyboard focus indicator visible | Pass | - | Custom cyan focus ring applied consistently |
Part 3: Issue Tracker
| ID | Criterion | Page/Component | Description | Severity | Owner | Deadline | Status |
|---|---|---|---|---|---|---|---|
| A-001 | 1.4.3 | Wizard, all steps | "Skip" link has 2.8:1 contrast ratio. Needs 4.5:1 minimum | Critical | Jamie L. | Mar 10 | Open |
| A-002 | 2.1.1 | Wizard, Step 3 | Template selection cards lack keyboard interaction. No role="button" or tabindex | Critical | Dev Team | Mar 10 | Open |
| A-003 | 2.4.3 | Wizard, Step 2 | Tab order skips company name and team size fields | Major | Jamie L. | Mar 14 | Open |
| A-004 | 1.1.1 | Wizard, all steps | Illustration alt text is empty. Needs descriptive text for each step | Major | Content | Mar 14 | Open |
Part 4: Summary and Sign-off
Total issues found: 7
Critical: 2 | Major: 3 | Minor: 2
Overall assessment: ☑ Fail. Two critical issues prevent keyboard-only users from completing onboarding.
Tested by: Sarah Chen, March 4, 2026
Reviewed by: Marcus Rivera, March 4, 2026
Key Takeaways
- Run automated accessibility scans (axe, Lighthouse) on every PR. They catch 30-40% of issues automatically and cost nothing to run.
- Keyboard navigation testing catches the most impactful issues. If a user cannot tab through your core flow, screen readers will not help either.
- Color contrast failures are the most common WCAG violation. Use a contrast checker during design, not after development.
- Test with real assistive technology, not just automated tools. Screen reader behavior varies significantly between VoiceOver, NVDA, and JAWS.
- Severity scoring prevents accessibility debt from piling up. Critical issues block launch. Major issues get a fix deadline. Minor issues enter the backlog with visibility.
- Accessibility testing is not a one-time event. Schedule quarterly audits and integrate automated checks into your CI/CD pipeline.