Hands-On · WCAG 2.2

Accessibility Labs — WCAG 2.2 Hands-On

Stop reading about accessibility and start testing it.

This is a practical path, not a tour of the standard. Each lesson hands you real components — a date picker, a modal, a status banner — and asks you to audit them against named WCAG 2.2 AA success criteria, find the keyboard trap, and write screen-reader test steps another tester could re-run. Every exercise marks your work against a model answer. Built for the NZ Government Web Accessibility Standard 1.2, with All-of-Government, RealMe, Waka Kotahi, and Te Whatu Ora examples throughout.

Start with Lesson 1 → Read the concepts first

This path covers

WCAG 2.2 AA in Practice Keyboard-Only Testing Screen-Reader Testing NZ Government Standard 1.2

Standard alignment

WCAG 2.2 AA

The NZ Government Web Accessibility Standard 1.2 requires public service and non-public service department websites to meet WCAG 2.2 Level AA. This path teaches you to test against that bar on the kinds of systems NZ testers actually work on.

Who this is for

Testers who can read HTML and want to run accessibility tests themselves rather than wait for an annual audit. No assistive-technology experience assumed — the screen-reader lesson starts from first principles.

The 3 lessons

Spot it, fix it, build it — against WCAG 2.2 AA

Lesson 1

WCAG 2.2 AA in Practice

The POUR principles as test lenses. The new 2.2 success criteria — focus appearance, dragging alternatives, target size, redundant entry. How to test a component against a specific numbered criterion, and the NZ Government standard that makes AA mandatory.

~30 min read · ~75 min with exercises · WCAG 2.2

Lesson 2

Keyboard-Only Testing

Put the mouse down. Tab order, focus management, visible focus indicators, keyboard traps, and skip links. The ARIA pitfalls that break keyboard users, and how to test a modal, a menu, and a custom dropdown without ever clicking.

~30 min read · ~70 min with exercises · WCAG 2.2

Lesson 3

Screen-Reader Testing

How a screen reader builds a picture of a page. Semantic HTML, alt-text quality, accessible names, roles, and live regions. Writing reproducible screen-reader test steps a developer can follow — using NVDA and VoiceOver concepts.

~30 min read · ~75 min with exercises · WCAG 2.2

Why this path

Accessibility is a test discipline, not a checklist

Most teams treat accessibility as an annual audit that lands as a PDF of failures nobody can reproduce. That is too late and too vague. By the time the audit arrives, the patterns that caused the failures are everywhere in the product, and the report says “contrast insufficient” without telling you which element, on which page, against which criterion.

A tester who can run accessibility checks during the sprint changes that. You catch the keyboard trap in the new modal before it ships. You flag the unlabelled icon button in the pull request, not the audit. You write a screen-reader defect a developer can actually re-run. That is the difference between accessibility as a compliance event and accessibility as testing.

In NZ this is not optional. The NZ Government Web Accessibility Standard 1.2 binds public service and non-public service departments to WCAG 2.2 Level AA. RealMe, the All-of-Government channels, Waka Kotahi services, and Te Whatu Ora platforms all sit under that bar. If a service makes a decision about a person or lets them transact with government, it has to be usable by people who navigate with a keyboard, a screen reader, or magnification. This path teaches you to test for exactly that — with model answers, so you can mark your own work as you go.

Pairs with

Concepts