Accessibility Testing

1 The Hook

Sarah is a chartered accountant in Wellington. She has been blind since birth and uses a screen reader (NVDA) to do her job. Last month, her firm switched to a new cloud-based tax filing system. On her first attempt, she got stuck on the login page for 20 minutes.

The problem? The "Sign In" button was a <div> with a click handler, not a real <button>. Her screen reader could not find it. The error messages appeared as red text with no ARIA live regions, so she never knew her password was wrong. The CAPTCHA had no audio alternative.

Sarah complained to her firm's IT director. The IT director escalated to the vendor. The vendor faced a complaint under the NZ Human Rights Act. And the development team spent three weeks remediating a problem that would have taken 30 minutes to catch during development.

Accessibility is not a feature. It is a fundamental quality of software.

In NZ, approximately 1.1 million people have some form of disability. That is nearly a quarter of the population. Vision impairment, motor disabilities, cognitive differences, and hearing loss all affect how people interact with technology. Accessibility testing is how we verify that our products do not exclude them.

2 The Rule

It is not about adding a "special version" for disabled users. It is about building one product that works for everyone: keyboard users, screen reader users, voice control users, people with tremors, people with colour blindness, and people with cognitive disabilities.

3 The Analogy

4 WCAG 2.1: The Four Principles

The Web Content Accessibility Guidelines (WCAG) are the international standard. They are organised around four principles, memorised as POUR:

Principle	What it means	Example failures
Perceivable	Information must be presentable in ways users can perceive	Images without alt text, videos without captions, colour-only indicators
Operable	Interface components must be operable by all users	Mouse-only interactions, no keyboard shortcuts, auto-playing content with no pause
Understandable	Information and operation must be understandable	Jargon-filled error messages, unpredictable navigation, no input validation feedback
Robust	Content must work with current and future assistive technologies	Invalid HTML, missing ARIA labels, JavaScript that breaks screen readers

Conformance levels: WCAG defines three levels — A (minimum), AA (standard), and AAA (enhanced). Most organisations, including NZ government, target WCAG 2.1 AA as their baseline.

5 Testing Techniques

Keyboard Navigation Testing

Unplug your mouse. Can you use every feature with only Tab, Enter, Space, Arrow keys, and Escape?

• Tab order follows the visual reading order (left to right, top to bottom)
• Focus indicator is always visible (never hidden by CSS outline: none without replacement)
• Trap-free navigation (Tab never gets stuck in a modal or widget)
• Skip links exist to bypass repeated navigation
• Custom controls (dropdowns, tabs, carousels) are fully keyboard-operable

Screen Reader Testing

Download NVDA (free, Windows) or use VoiceOver (built into macOS and iOS). Close your eyes and try to complete a core task.

• All images have meaningful alt text (or are marked decorative with alt="")
• Form fields have associated labels, not just placeholder text
• Headings create a logical document outline (h1 → h2 → h3)
• Dynamic content updates are announced (ARIA live regions)
• Tables have proper headers (<th>) and scope attributes
• Links make sense out of context ("Read more" is bad; "Read more about KiwiSaver" is good)

Colour Contrast & Visual Testing

Approximately 1 in 12 NZ men and 1 in 200 women have some form of colour blindness.

• Text contrast ratio is at least 4.5:1 for normal text, 3:1 for large text
• Information is never conveyed by colour alone (add icons, labels, or patterns)
• Text remains readable at 200% browser zoom
• Content reflows without horizontal scrolling at 400% zoom
• Flashing content is absent or below the threshold that triggers seizures

Cognitive Accessibility

• Error messages explain what went wrong and how to fix it
• Form validation happens inline, not only on submit
• Consistent navigation and layout across pages
• Adequate time limits with ability to extend
• Plain language; avoid unnecessary jargon

6 Tools in Action

Important: Automated tools catch only 20-30% of accessibility issues. A tool can tell you an image lacks alt text, but it cannot tell you if the alt text is meaningful. It can detect missing labels, but not whether a keyboard user can operate a custom date picker. Manual testing with a keyboard and screen reader is mandatory for WCAG compliance.

7 NZ Legal Context

Accessibility is not just ethical — in NZ, it is increasingly a legal requirement.

• Human Rights Act 1993: It is unlawful to discriminate on the basis of disability. This includes providing goods and services through inaccessible digital channels.
• NZ Government Web Accessibility Standard: All public service departments and Crown entities must meet WCAG 2.1 AA for web content. This standard is legally binding under the State Sector Act.
• UN Convention on the Rights of Persons with Disabilities: NZ is a signatory. Article 9 requires accessible ICT for people with disabilities.

For testers: If you work on government contracts, accessibility testing is not optional. Document your testing methodology, keep records of WCAG conformance, and include accessibility in your Definition of Done.

8 Common Mistakes

9 Now You Try

10 Self-Check

Click each question to reveal the answer.