Accessibility Testing
Accessibility isn't a feature you add at the end. It's a quality characteristic you verify at every layer. One in four New Zealanders has a disability. Their experience is your test coverage gap.
1 The Hook — Why This Matters
In 2022, an IRD online tax form was released after passing functional testing with a clean bill of health. Within a week, the Blind Foundation NZ received multiple complaints. Screen reader users couldn't complete the form because the error messages were never announced. Keyboard users got trapped in a date picker with no escape route. A user with low vision, zoomed to 200%, found the sidebar overlapping the input fields so badly that the "Submit" button was completely hidden.
The fix required a two-week emergency sprint. The cost of retrofitting accessibility was five times what it would have cost to build it in. Worse, the IRD faced reputational damage and questions from the Human Rights Commission about compliance with the NZ Human Rights Act. Accessibility bugs are legal, ethical, and business risks — not just nice-to-haves.
2 The Rule — The One-Sentence Version
If a user cannot perceive, operate, understand, or rely on your interface with the tools they use, it is a bug — full stop.
WCAG 2.1 organises accessibility into four principles: Perceivable (can users perceive the content?), Operable (can users interact with it?), Understandable (is the content and operation clear?), and Robust (does it work with assistive technologies?). Each principle has testable success criteria at three levels: A (minimum), AA (standard), and AAA (highest). For most NZ government and enterprise work, AA is the baseline. AAA is aspirational.
3 The Analogy — Think Of It Like...
Designing a building with only stairs, then adding a ramp at the back door.
If you design a building with stairs everywhere and then bolt a ramp onto the loading dock, wheelchair users can technically enter — but they can't use the café, the toilets, or the lifts without assistance. Accessibility testing is checking every entrance, every corridor, and every room. Not just the front door. Not just the automated scan. Every path a real person takes.
4 Watch Me Do It — Step by Step
Here is a real NZ example using an IRD-style government form. Follow these steps in order; each layer finds bugs the previous layer missed.
-
Run an automated scan first
Use axe DevTools, Lighthouse, or WAVE. Automated tools catch ~30% of WCAG issues instantly: missing alt text, invalid ARIA, insufficient contrast ratios, missing form labels. Treat the scan as a fast first pass, not a final verdict.
Found: Missing alt text on an information icon next to the IRD number field. The icon conveyed meaning visually but was invisible to screen readers.
-
Test keyboard-only navigation
Put the mouse away. Use Tab, Shift+Tab, Enter, Space, and arrow keys. Every interactive element must be reachable and activatable. Focus must always be visible. There must be no keyboard traps.
Found: A tab trap in the date picker. Once opened, Tab cycled endlessly inside the widget. Escape did not close it. A keyboard user was stuck.
-
Test with a screen reader
Use NVDA (free, Windows) or VoiceOver (built into macOS/iOS). Close your eyes. Tab through the page. Verify you understand every state, every heading, and every form field without sight.
Found: Form labels were not programmatically associated with inputs. The screen reader announced "edit, blank" instead of "IRD number, edit, blank." Users had to guess what each field was for.
-
Zoom to 200% and 400%
Use browser zoom (Ctrl/Cmd + Plus). At 200%, text must reflow without horizontal scrolling. At 400%, content must still be readable and functional. This tests for users with low vision who rely on magnification.
Found: At 200% zoom, the sidebar overlapped the main form content, obscuring the "Submit" button. The layout used fixed widths instead of relative units.
- Check colour and contrast Verify text contrast ratios meet WCAG AA: 4.5:1 for normal text, 3:1 for large text (18px+ or 14px+ bold). Never rely on colour alone to convey meaning. Test with a colour-blindness simulator.
-
Test mobile accessibility
Use TalkBack (Android) or VoiceOver (iOS). Verify touch targets are at least 44×44 CSS pixels. Check that the numeric keyboard appears for phone/IRD number fields. Test landscape and portrait orientations.
Found: The phone number field on mobile did not trigger the numeric keyboard, forcing screen reader users to hunt for digits in the full alphabetic layout.
5 When to Use It / When NOT to Use It
✅ Prioritise accessibility when...
- The site serves the public or government (legal obligation in NZ)
- You are building forms, payments, or account creation flows
- The product has a diverse user base including older adults
- You are releasing to markets with strong accessibility laws
- You want to improve SEO (accessible sites are indexable sites)
- You are building design systems or component libraries
❌ Don't fall into these traps...
- Relying solely on automated tools (they miss ~70% of issues)
- Testing with only one screen reader (behaviour varies)
- Overusing ARIA (bad ARIA is worse than no ARIA)
- Ignoring focus management and keyboard traps
- Testing only at design breakpoints, not at 200%+ zoom
- Treating accessibility as a final QA gate instead of shift-left
6 Common Mistakes — Don't Do This
🚫 Relying solely on automated tools
I used to think: If axe says zero violations, the page is accessible.
Actually: Automated tools catch only ~30% of WCAG issues. They cannot judge whether alt text is meaningful, whether focus order is logical, or whether a custom component is operable by keyboard. Automated scans are a starting point, not a finish line. Manual testing with keyboard and screen reader is mandatory.
🚫 Overusing ARIA
I used to think: Adding more ARIA roles and attributes always helps screen reader users.
Actually: Incorrect ARIA is worse than no ARIA. A role="button" on a <div> without keyboard handlers and focus management creates a trap. Native HTML elements (real <button>, <a>, <input>) come with built-in accessibility. Use ARIA only when HTML semantics are insufficient.
🚫 Ignoring focus management
I used to think: If the page looks right, keyboard users can figure it out.
Actually: Focus is the cursor of the keyboard user. If focus disappears after a modal opens, if it jumps randomly around the page, or if it is not trapped inside a modal, the user is lost. Test focus order on every interactive flow. It should follow the visual reading order and never disappear.
7 Now You Try — Interview Warm-Up
Question: You're testing a login form. The developer added aria-label="Login" to the submit button and called it accessible. List three additional things you would check before agreeing.
Write your three checks before revealing.
Three critical additional checks:
- Keyboard operability: Can you Tab to the button, activate it with Enter/Space, and is focus always visible? A labelled button that can't receive keyboard focus is still a blocker.
- Form label association: Do the email and password inputs have programmatically associated labels? A screen reader user needs to hear "Email address, edit" not just "edit, blank."
- Error announcement: When login fails, is the error message announced to screen readers? Many forms show a red banner that sighted users see but screen reader users never hear.
The aria-label on the button is good, but it only solves one of roughly fifteen accessibility considerations for a login form.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to audit real applications.
Q1. What does POUR stand for in WCAG 2.1?
Perceivable (can users perceive the content?), Operable (can they interact with it?), Understandable (is the content and operation clear?), Robust (does it work with assistive technologies?). Every WCAG success criterion maps to one of these four principles.
Q2. What are the minimum contrast ratios for WCAG AA?
4.5:1 for normal text, and 3:1 for large text (18px+ or 14px+ bold). Large text has a lower threshold because larger characters are easier to read at lower contrast. Also, UI components and graphical objects need 3:1 against adjacent colours.
Q3. Why is it important to test at 200% and 400% zoom?
Because users with low vision rely on browser zoom to read content. At 200%, text must reflow without horizontal scrolling. At 400%, content must still be readable and functional. Fixed-width layouts, overlapping elements, and truncated buttons are common failures at these zoom levels that automated tools rarely catch.
9 Interview Prep — Common Questions
Q. "How do you test with a screen reader?"
I close my eyes and navigate using only the screen reader. I Tab through interactive elements to verify focus order and operability. I check that headings form a logical hierarchy (H1 → H2 → H3), that form inputs have associated labels, that error messages are announced via aria-live regions, and that I can complete core tasks without any visual reference. I test with at least two screen readers: NVDA on Windows and VoiceOver on macOS or iOS.
Q. "What percentage of accessibility issues can automated tools catch?"
Roughly 30% of WCAG success criteria can be fully tested by automated tools: missing alt text, invalid ARIA, insufficient contrast ratios, missing form labels, and empty headings. The remaining 70% require manual testing: logical focus order, meaningful alt text, keyboard operability, screen reader experience, and usability under magnification. I always run automated scans first for speed, then follow with structured manual testing.
Q. "What is 'shift left' in accessibility?"
It means building accessibility into design and development, not leaving it as a final QA gate. I review designs for colour contrast and focus indicators before code is written. I test component libraries in isolation. I run axe-core in CI/CD on every pull request. The earlier you catch an accessibility issue, the cheaper it is to fix. Retrofitting accessibility into a shipped product costs 5–10x more than building it in.
Q. "What are the WCAG 2.1 levels and which should we target?"
Level A is the minimum: no keyboard traps, alt text for images, captions for prerecorded video. Level AA is the standard required by most jurisdictions, including NZ government: 4.5:1 contrast, resizable text to 200%, consistent navigation, error prevention. Level AAA is the highest: sign language for video, 7:1 contrast, extended audio description. I target AA as the baseline for all projects and AAA for critical public services.