Accessibility Testing (WCAG)

What it is

Accessibility testing checks whether a system works for people who use it differently — via keyboard instead of mouse, via screen reader instead of eyes, via switch control instead of touchscreen, or with cognitive differences that require clear language and consistent layout.

The standard that governs this work is the Web Content Accessibility Guidelines (WCAG), currently at version 2.1. In most professional contexts, WCAG 2.1 Level AA is the target. Level A is the minimum; Level AAA is aspirational. AA is what government, healthcare, and most enterprise systems are expected to meet.

NZ context

New Zealand has strong legal and policy foundations for accessibility:

• 1 in 4 New Zealanders has a disability. This is not a niche requirement — it affects a quarter of your user base.
• Human Rights Act 1993 prohibits discrimination on the grounds of disability in the provision of goods and services. An inaccessible website can constitute unlawful discrimination.
• NZ Government Web Standards require all government websites to meet WCAG 2.1 AA. If you work on any government or public sector project in NZ, AA compliance is mandatory.
• NZ Disability Strategy 2016–2026 sets a national vision for a fully inclusive New Zealand society.
• Te reo Māori is an official language of New Zealand. Accessibility must also consider bilingual content — screen readers need correct language tagging (lang="mi" on Māori text blocks) to pronounce te reo correctly.

WCAG 2.1 AA — the four principles (POUR)

All WCAG success criteria are organised under four principles. Understanding these helps you reason about why a particular requirement exists, not just what it requires.

Manual checks every tester should do

These checks require no specialist tools — just a browser and keyboard:

ARIA: when to use it and when not to

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes that add accessibility metadata to elements — roles, states, and properties that assistive technologies use when native HTML doesn’t provide enough information.

The first rule of ARIA is: don’t use ARIA if you can use a native HTML element instead. A <button> is focusable, activatable by Enter/Space, and announces itself as a button to screen readers — automatically. A <div role="button"> requires you to manually handle all of that. Native HTML is always more reliable.

Where ARIA is appropriate: custom widgets that have no native HTML equivalent (data grid, combobox with autocomplete, drag-and-drop interface, date picker). Use ARIA to communicate state: aria-expanded="true/false" on accordion headers, aria-selected on tabs, aria-live regions to announce dynamic content updates to screen readers.

When reviewing ARIA usage in a product, the key check is: does the ARIA match the visual state? If a dropdown is open and aria-expanded is still "false", that’s a bug.

Tools

• axe DevTools (browser extension, free) — runs automated checks on the current page and reports violations with explanations and links to WCAG criteria. The most widely used accessibility automated tool.
• WAVE (browser extension, free) — overlays visual indicators directly on the page; good for quickly spotting missing labels, empty links, and contrast issues
• Lighthouse (built into Chrome DevTools) — accessibility audit as part of a broader performance/quality report; good for CI integration
• Colour Contrast Analyser (desktop app, free from The Paciello Group) — lets you pick any two colours on screen and get the contrast ratio instantly
• Screen readers — NVDA (Windows, free), JAWS (Windows, paid), VoiceOver (macOS/iOS, built-in), TalkBack (Android, built-in). At minimum, run through the main user journey with NVDA + Chrome to catch the most impactful issues.

Common bugs

• Placeholder used as label — placeholder text disappears when the user starts typing, leaving no visible label; screen readers may not announce it at all in some contexts
• Colour as the only differentiator — red = error, green = success, with no other indicator. Red-green colour blindness affects approximately 8% of men. Use icons, text labels, or patterns in addition to colour.
• Button with no accessible name — <button><img src="close.png"></button> is announced as “button” by screen readers with no context. Add aria-label="Close" or use a visually-hidden text span.
• Modal that doesn’t return focus — modal opens, focus moves into it correctly. Modal closes. Focus drops to the top of the page instead of returning to the element that opened the modal.
• Custom dropdown not keyboard accessible — a dropdown built with <div> and <ul> that requires mouse hover to open and can’t be used with Tab or arrow keys
• Dynamic content not announced — an error message appears on screen after form submission, but no aria-live region announces it to screen reader users who can’t see the page change

Tips

• Include accessibility in your definition of done — axe DevTools passes + keyboard navigation check should be checklist items before any story is marked done
• Raise contrast failures with actual values — when reporting a contrast bug, include the foreground colour, background colour, and the measured ratio (e.g. 2.8:1 against required 4.5:1). This gives designers exactly what they need to fix it.
• Test with zoom at 200% — WCAG 1.4.4 requires content to be readable at 200% zoom without loss of content or functionality. Many layouts break at high zoom and are never tested.
• Te reo Māori content — if your product includes te reo Māori text, ensure it is wrapped in <span lang="mi"> so screen readers switch to the correct language voice engine. Without this, the Māori text is mispronounced in English phonetics.