Accessibility Testing Learning Path: Start Here

In short: you learn accessibility testing in 6 milestones, starting on a practice page with 14 planted problems and its fixed twin, and ending with a real audit report. Each milestone has an answer key or a tested solution.

How to use this page

Read this page once to see the plan. Then, for each milestone, follow the same four steps: learn → test → check → commit. Come back here whenever you're unsure what to do next.

Before you start

• The practice lab saved locally (site/broken.html, site/fixed.html).
• Basic HTML: elements, attributes, forms.
• A screen reader you can start: VoiceOver (built into macOS/iOS), NVDA (free for Windows) or TalkBack (Android).
• From Milestone 3: Node.js 20+ for Playwright and axe.

The pages in this learning path

Page	What it's for	When to open it
This roadmap	The plan and self-checks	At the start of each milestone
Accessibility cheat sheet	Learn each idea: broken vs fixed, tests with real results	The "learn" step
Milestones & Mini-Projects	Tasks, expected results, answer keys	The "test" and "check" steps
Quick Reference	WCAG by check, numbers, keys, screen-reader commands, templates	Any time
Best Practices	Habits that get barriers found and fixed	After Milestone 2, then before every release
Accessibility testing guide	The laws and the audit service	For the deeper "why"

The milestones

Milestone	You learn	You work on	Rough time
1	Who it's for, POUR, semantics, the accessibility tree	Inspecting two pages	1 week
2	Names, contrast, keyboard, focus, forms, structure	Manual audit: find 14 issues	1–2 weeks
3	axe, tags, what tools can't find	Automated scans	1 week
4	Keyboard, focus and form tests in code	A test suite that locks in fixes	1 week
5	Screen readers, zoom, reflow, motion, WCAG 2.2	Listening and resizing	1–2 weeks
6	Audits, severity, reporting, CI	A real audit and report	1–2 weeks

Times assume about 5 hours a week.

For each milestone: learn (cheat-sheet sections below) → test (the milestone tasks) → check (answer key) → commit your notes, tests and reports.

Milestone 1: Semantics & the accessibility tree

Learn: What accessibility is · Who it's for · WCAG & POUR · Levels & laws · Semantic HTML

Work on: Inspecting two pages

Check yourself:

• Name the four POUR principles with one example each.
• Why does a <div> with onclick fail keyboard users?
• Which WCAG level do most laws require?

Milestone 2: Manual audit

Learn: Text alternatives · Names & labels · Colour & contrast · Keyboard access · Focus · Headings & landmarks · Forms & errors · Status messages · Quick Reference: Manual check routine

Work on: Find the 14 issues

Then read: Best Practices, sections 1–4.

Check yourself:

• What's the minimum contrast for normal text?
• Why isn't a placeholder a label?
• How must an error be shown so everyone gets it?

Milestone 3: Automated checks

Learn: ARIA basics · Automated checks (axe) · Quick Reference: axe tags and rules

Work on: Automated scans

Check yourself:

• What share of your 14 issues did axe find?
• What does axe's incomplete list mean?
• What's the difference between the wcag2aa and best-practice tags?

Milestone 4: Tests in code

Learn: Keyboard tests in code · Quick Reference: Playwright assertions, Keyboard expectations

Work on: A suite that locks in fixes

Check yourself:

• How do you test focus order in code?
• What does toHaveAccessibleDescription check?

Milestone 5: Screen readers, zoom & WCAG 2.2

Learn: Screen readers · Zoom, reflow & spacing · Motion & timing · Mobile & touch · New in WCAG 2.2 · Quick Reference: Screen-reader commands

Work on: Listening and resizing

Check yourself:

• How do you jump heading to heading in your screen reader?
• What width do you test reflow at, and why that number?
• Name three criteria added in WCAG 2.2.

Milestone 6: Audit & report

Learn: Running an audit · Accessibility in CI · Quick Reference: Issue template, Severity

Work on: A real audit

Then read: Best Practices, sections 5–10.

Check yourself:

• What makes an issue "blocker" severity?
• Why group issues by component?
• Why shouldn't an audit report promise legal compliance?

When you get stuck

Problem	What to do
Screen reader is overwhelming	Learn 4 commands: next item, activate, next heading, stop speaking. Turn speech rate down
Not sure which criterion applies	Search the W3C "Understanding WCAG 2.2" page for the symptom
axe says "needs review"	Check that element by hand — it's the tool asking you
Contrast tool disagrees with axe	Check the exact colours (including transparency and background images) with a contrast analyser

What's next

• Mobile apps: Mobile testing learning path.
• Automation depth: Test automation learning path.
• Certification: IAAP CPACC (concepts) and WAS (technical); the US DHS Trusted Tester programme.

Good resources: W3C WAI (WCAG, Understanding docs, ARIA Authoring Practices), and WebAIM articles and surveys.