Accessibility Testing (WCAG)
Verify that a system can be used by people with disabilities — including visual, hearing, motor, and cognitive impairments. In New Zealand, 1 in 4 people has a disability. Accessibility is not optional.
1 The Hook
A HealthNZ team launches an online form for booking a vaccination. It is tested the usual way: a sighted tester opens it with a mouse, fills the fields, clicks submit, sees the confirmation. Looks great. Signed off.
Then a blind nurse using NVDA tries to book. She tabs to the date field — but it is a custom <div> dropdown that only opens on mouse hover, so the keyboard cannot reach it. The submit button is an image with no label, announced only as “button.” When she submits with a missing field, the error shows as red text with no aria-live region, so her screen reader says nothing at all. From her side, the form is simply broken. She cannot book a basic health appointment online.
None of this showed up in the original test because the test was done the way the developer built it: sighted, with a mouse. A quarter of New Zealanders have a disability, and for many of them the mouse-and-eyes happy path is exactly the path they cannot take. Accessibility testing is testing the paths the original team never used.
Accessibility testing means exercising a system the way users with disabilities actually use it — by keyboard only, by screen reader, and at 200% zoom — measured against WCAG 2.1 Level AA, the standard mandated for all NZ government services. Use it on any user-facing interface, especially in health, welfare, and financial services where locking someone out can constitute unlawful discrimination under the Human Rights Act 1993. The most common mistake is treating a zero-violation axe DevTools result as a pass: automated tools catch only around 30% of issues, and the rest — focus management, coherent screen-reader announcements, keyboard reachability of custom components — require manual testing to find.
The most expensive accessibility defects I've seen in NZ government projects are never caught by axe and never appear in a manual keyboard tab-through: they're focus management failures in single-page applications. A React or Angular app can pass every automated check and every keyboard test on individual pages, then completely disorient a screen-reader user the moment they navigate between routes — because the virtual DOM swaps content silently and the user's cursor stays exactly where it was on the previous page. On a HealthNZ health portal I reviewed, a blind user navigating from the appointment list to a booking form heard nothing change — no announcement, no focus shift — and had no idea she'd moved to a new screen. Your test plan must include route-transition checks: navigate between pages with NVDA running and listen for a heading announcement at the new page top. If you hear nothing, it's broken.
From the field
A Wellington-based government agency was migrating their benefit-application portal to a new React SPA. The team ran axe DevTools on every page and passed the NZ Government Web Standards checklist before UAT — zero violations, all labels present, keyboard tab-through confirmed. During UAT a screen-reader user attempted to switch between steps in a multi-page wizard and heard nothing: no heading announcement, no confirmation of progress, no indication that anything had changed. The SPA was swapping content silently on each route transition and never moving focus to the new step — a WCAG 2.4.3 Focus Order failure that axe cannot detect and a sighted keyboard tester will never notice because they can see the new content appear. The agency deferred the launch for two weeks to retrofit focus management across the entire wizard. The lesson generalises: on any SPA, route-transition testing with NVDA running is not optional — it is the one check that no tool replaces.
2 The Rule
Test the system the way people with disabilities actually use it — by keyboard, by screen reader, at 200% zoom — against WCAG 2.1 AA, because the happy path built with a mouse and working eyes hides the defects that lock people out.
3 The Analogy
A building with a grand front staircase and no ramp.
A new Auckland library opens with a beautiful stone staircase at the entrance. The architect walked up it, the builders walked up it, the official who cut the ribbon walked up it — everyone who signed off could climb stairs, so nobody noticed there is no ramp, no lift, and the door is too narrow for a wheelchair. The building “works” for everyone who tested it, and is unusable for the person who arrives in a wheelchair or pushing a pram.
Accessibility testing is sending someone in a wheelchair to the door before opening day. A keyboard-only run, a screen-reader pass, a zoom check — those are the wheelchair at the entrance, finding the missing ramp while it can still be built, instead of after the doors are open.
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.
Automated tools catch only ~30% of accessibility issues. The rest require human judgement — reading the page with a screen reader, tabbing through a form, checking that an error message is actually useful. This is why accessibility testing is a skill, not just a tool run.
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.
| Principle | What it means | Key examples |
|---|---|---|
| Perceivable | Content must be presentable to users in ways they can perceive. Nothing should be invisible to all of a user’s senses. | Alt text for images; captions for video; colour contrast ratio minimum 4.5:1 for normal text; don’t convey information by colour alone |
| Operable | All functionality must be operable via keyboard (or other input besides mouse). No content should cause seizures. | All interactive elements reachable by Tab; no keyboard traps; skip navigation link; no flashing content faster than 3 times/second; sufficient time to complete tasks |
| Understandable | Content and operation must be understandable. Users must be able to understand both the information and how to operate the interface. | Language of page declared (lang="en-NZ"); form labels are visible and associated; error messages are descriptive; consistent navigation across pages |
| Robust | Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies. | Valid HTML; ARIA used correctly; custom components have proper roles, names, and states; works with current screen readers (NVDA, JAWS, VoiceOver) |
Manual checks every tester should do
These checks require no specialist tools — just a browser and keyboard:
| Check | How to test | What a bug looks like |
|---|---|---|
| Keyboard navigation | Put your mouse aside. Tab through the entire page. Shift+Tab to go back. Enter/Space to activate buttons and links. | Any interactive element unreachable by keyboard; focus disappears; wrong Tab order; modal opens but focus doesn’t move into it |
| Focus indicator visible | Tab through the page and watch the focus ring (the outline around focused elements). | Focus ring removed with CSS (outline: none); focused element is visually indistinguishable from unfocused element |
| Colour contrast | Use browser DevTools Accessibility panel, or the free Colour Contrast Analyser tool. Check text against its background. | Contrast ratio below 4.5:1 for normal text, or below 3:1 for large text (18pt+ or 14pt+ bold) |
| Image alt text | Right-click each image → Inspect. Check the alt attribute. |
Missing alt attribute; alt="image" or alt="photo" (meaningless); decorative images without alt="" |
| Form labels | Click on the label text for each form field. The cursor should jump to the input. | Clicking the label does nothing (label not associated with input); placeholder used instead of a real label |
| Error messages | Submit a form with invalid data. Read the error message. | “Invalid input” (doesn’t say what’s wrong); error only indicated by red colour; error not linked to the field it describes |
| Heading structure | Use the headings panel in browser DevTools or the WAVE extension to view the heading outline. | No h1 on the page; h1 jumps straight to h3 (skipped levels); headings used for styling rather than structure |
| Link text | Read the link text out of context. Does it make sense? | “Click here”, “Read more”, “Learn more” with no surrounding context; screen reader users hear a list of “click here click here click here” |
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. Addaria-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-liveregion announces it to screen reader users who can’t see the page change
Tips
Automate first, then test manually. Install the axe DevTools browser extension and run it on every page before releasing. It’ll catch the mechanical issues (missing alt text, duplicate IDs, invalid ARIA). Then put your mouse away and tab through the whole page — automated tools miss what keyboard testing catches, especially focus management in dynamic components.
- 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.
4 Industry Reality
- Most projects have no accessibility acceptance criteria in their user stories. You will raise an axe DevTools finding and the product owner will say “log it as a nice-to-have.” Senior testers push back early — accessibility is a legal requirement, not a feature. Frame it under the Human Rights Act 1993 and the conversation changes.
- Legacy codebases are riddled with placeholder-as-label patterns, custom
<div>buttons, and hardcoded colours that fail contrast. On a retro product built in 2014, you will not fix these in one sprint. The pragmatic move is a prioritised risk log: keyboard traps and unlabelled controls first (they lock people out entirely), colour contrast second, te reo language tags third. - Automated tools run in CI will report 15–30 axe violations on a typical government form. Most developers have never seen an axe report before. Your job includes triage and translation: identify which findings are genuine blockers versus low-risk; write them in plain language with the WCAG criterion, the measured value, and a concrete fix. A finding that says “contrast ratio 2.8:1, needs 4.5:1, change text from #767676 to #595959” gets fixed; “contrast issue found” gets ignored.
- Screen-reader testing with NVDA or VoiceOver is uncomfortable at first. Most testers avoid it and rely entirely on axe. But axe cannot tell you whether a modal focus-management flow sounds coherent, whether a dynamic error message is actually heard, or whether an accordion's aria-expanded announcement is meaningful. Block two hours to learn NVDA + Chrome basics. You will catch defects no one else on the team will find.
- NZ government agencies (MBIE, CoverNZ, FamiliesNZ, Revenue NZ) take WCAG AA seriously post-audit. HealthNZ digital projects explicitly require accessibility sign-off. In private sector, insurance, banking (Harbour Bank, Coastal Bank, Pacific Bank), and KiwiSaver providers are increasingly facing internal audits — especially after the FMA began scrutinising digital service equity. Knowing WCAG well is a genuine career differentiator in the NZ market.
Senior engineer insight
The project that changed how I approach accessibility testing was an CoverNZ online claims form. We had axe at zero violations, keyboard nav signed off, and I was about to close the test cycle — then a colleague who uses a screen reader sat down with it. She got through the first two steps fine, then hit the “upload supporting documents” section and heard nothing when the file input activated. The component was a custom drag-and-drop zone built entirely in JavaScript with no fallback <input type="file">. Not one automated check had flagged it, not one sighted keyboard tester had noticed — because sighted testers can see the upload zone appear and assume it is working. That session changed my rule: every release gets at least one NVDA + Chrome pass on the happy path, no exceptions, even when axe is clean and the keyboard tab-through looks fine.
The most common mistake I see from graduates is treating accessibility testing as a checklist to run once at the end of a sprint — they run axe, tick the box, and move on, without ever putting the mouse down and actually completing a user journey by keyboard alone.
5 When to Use It — and When Not To
✓ Use it when
- The product is a government or public-sector website or app in NZ (WCAG 2.1 AA is mandatory under the NZ Government Web Standards)
- The user base includes members of the public — any user-facing interface where you cannot control who shows up could be used by someone with a disability
- The application handles health, welfare, financial, or emergency services — the stakes of locking someone out are high and the HRA 1993 exposure is real
- A new feature adds interactive components: modals, date pickers, carousels, data tables, autocomplete inputs, or custom dropdowns — these are where accessibility breaks most often
- The team has included accessibility acceptance criteria in the story definition of done — your test pass enforces the agreed standard
✗ Skip it when
- The interface is a purely internal admin tool used only by a known, fixed group of internal staff who have all confirmed they do not need assistive technology — and even then, document that decision
- The component has not changed since the last accessibility audit — do not re-test static, stable pages on every regression cycle; prioritise changed or new surfaces
- The only deliverable is a raw data API (no UI) — accessibility applies to the presentation layer; if there is no HTML rendered to a user, WCAG success criteria do not apply
- You have already run axe, the page has zero violations, and it contains only static content with no interactive elements — manual keyboard testing adds minimal value here; redeploy the time to components with real interaction
Context guide
How the right level of Accessibility Testing effort changes based on project context.
| Context | Priority | Why |
|---|---|---|
| NZ government or public-sector system (Revenue NZ, CoverNZ, Benefits NZ, HealthNZ, TransitNZ, RealMe) | Essential | WCAG 2.1 AA is a legal requirement under the NZ Government Web Standards; failure creates Human Rights Act 1993 exposure and real audit risk for the agency. |
| Regulated healthcare or financial services (KiwiSaver provider, health portal, CoverNZ claims, banking app) | High | FMA and HealthNZ digital-equity scrutiny is increasing; a blind user locked out of a KiwiSaver dashboard or CoverNZ claims form has direct legal recourse under the Human Rights Act. |
| Consumer-facing product or public portal (e-commerce, booking system, membership site, utility provider) | High | Any public-facing interface can be used by the 1-in-4 New Zealanders with a disability; you cannot control who arrives, and the Human Rights Act applies to the provision of goods and services. |
| Agile sprint work on an established product (new feature, component library upgrade, UI refactor) | Medium | Run a diff-based pass — re-test changed surfaces only (axe + keyboard tab-through); skip unchanged pages. Full re-audit every sprint is unaffordable; skipping entirely is too risky for any user-facing change. |
| Legacy system migration (older government portal, heritage banking UI, on-premise-to-cloud lift-and-shift) | Medium | Legacy codebases often carry hundreds of inherited violations; the pragmatic approach is a risk-prioritised backlog (keyboard traps first, then unlabelled controls, then contrast) rather than a full audit in one sprint. |
| Small startup or early-stage MVP with internal-only users and no public interface | Low | At minimum run axe in CI and do a keyboard tab-through; a full manual screen-reader pass can wait until the product reaches a public audience — but document the decision so it doesn’t get forgotten. |
Trade-offs
What you gain and what you give up when you choose Accessibility Testing.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Surfaces defects that every other technique misses — keyboard traps, focus failures, screen-reader incoherence — because it exercises paths the development team never used. | Time-intensive to do properly: a full NVDA + keyboard pass on a complex government form can take 2–4 hours per page, and that time is hard to defend in a sprint with a shrinking runway. | The sprint contains only back-end changes with no HTML rendered to a user — run axe in CI only and defer manual testing to the next UI change. |
| Legal and regulatory risk mitigation: WCAG 2.1 AA is mandated by the NZ Government Web Standards and backed by the Human Rights Act 1993 — documented test evidence protects the agency in an audit or complaint. | Automated tools (axe, Lighthouse) catch only ~30% of issues, so a clean automated report can create false confidence and cause teams to skip manual testing altogether. | The component is a purely internal admin tool used only by a known, fixed group of staff who have all confirmed they do not need assistive technology — document the decision and revisit if the user group changes. |
| Improvements benefit the entire user base, not just disabled users — better keyboard navigation helps power users, higher contrast helps users in bright sunlight, clear error messages help everyone. | Screen-reader testing requires specialist knowledge of NVDA/JAWS/VoiceOver — a tester who has never used a screen reader will miss critical issues and misinterpret normal announcements as bugs. | The team has no screen-reader experience — start with automated + keyboard-only testing and schedule a focused upskill session before attempting a full screen-reader pass. |
| Findings are objective and citation-backed — every defect maps to a WCAG success criterion with a measurable threshold, making it hard for stakeholders to dismiss as subjective opinion. | Legacy codebases can have hundreds of axe violations on first audit — the volume overwhelms teams who have never seen a report and has no clear remediation path without prioritisation. | You inherit a legacy product with 200+ violations — use exploratory testing first to identify keyboard traps and unlabelled controls, and build a risk-prioritised remediation backlog rather than trying to fix everything at once. |
| Catches single-page application focus-management failures that no other test type finds — route-transition bugs that leave screen-reader users stranded are invisible to functional and performance testing. | WCAG conformance does not guarantee usability for disabled users — a page can technically pass every AA criterion and still be confusing to navigate, because standards test compliance, not experience quality. | You want to know whether disabled users can efficiently complete a task — combine accessibility testing with usability testing that includes participants who use assistive technology. |
6 Best Practices
- ✓ Run axe DevTools as the first step on every new page or component — it catches the mechanical issues (missing labels, invalid ARIA, duplicate IDs) in under 30 seconds and clears the way for manual testing to focus on what automation misses
- ✓ Always test keyboard navigation with the mouse physically unplugged (or at least off the desk). If it is still in reach, you will reach for it. Keyboard-only testing done with a mouse nearby is not keyboard-only testing.
- ✓ Report contrast failures with numbers: state the foreground colour, background colour, measured ratio, and required ratio. “#767676 on #fff = 4.48:1, needs 4.5:1” gives the designer a precise target; “contrast issue” does not.
- ✓ Map every defect to a POUR principle and a WCAG success criterion (e.g. SC 1.4.3 Contrast Minimum). This turns a subjective finding into a standards citation that is harder to dismiss and easier for developers to look up.
- ✓ Test at 200% browser zoom on every release. Set it, then scroll through the whole page. Text reflow, horizontal scrollbars appearing, content getting clipped, and overlapping elements are all WCAG 1.4.4 failures — and they are almost never tested.
- ✓ Check every error state, not just the success path. Error messages announced only by colour, error text not linked to its field via
aria-describedby, and error regions withoutaria-liveare three of the most common bugs in form testing. - ✓ Inspect te reo Māori text with DevTools and verify
lang="mi"wrapping. Add this as a standard checklist item on any NZ project — it takes ten seconds to check and failing it renders te reo content unintelligible to assistive technology users. - ✓ Do at least one screen-reader pass per release, not just per project. Use NVDA + Chrome (free, widely tested). Tab through the main user journey and listen. If anything sounds wrong to you, it will sound wrong to a user.
- ✓ Write accessibility test cases as structured steps in your test management tool (Xray, Zephyr, TestRail), not freeform notes. This creates an auditable record and makes regression coverage visible to stakeholders.
- ✓ When a developer says “it works fine with a mouse,” demonstrate the failure live with a keyboard or screen reader. Showing beats telling. A 60-second demo in a review meeting changes priorities faster than a written bug report.
7 Common Misconceptions
❌ Myth: If axe DevTools reports zero violations, the page is accessible.
Reality: Automated tools like axe catch roughly 30% of accessibility issues. Zero axe violations means the mechanical rules pass — labels are present, IDs are unique, ARIA attributes are syntactically valid. It does not mean keyboard navigation works, that a screen reader can use the page coherently, that focus management after a modal closes is correct, or that meaningful alt text actually describes the image. A page can be completely unusable for a screen-reader user and still score zero axe violations.
❌ Myth: Accessibility is only relevant for blind users, and there aren’t many of them.
Reality: 1 in 4 New Zealanders has a disability. That includes low vision, colour blindness (affecting ~8% of men), motor impairments that prevent mouse use, cognitive conditions that require clear language and consistent layout, and temporary impairments like a broken arm or bright sunlight on a phone screen. Keyboard navigation benefits power users and users on tablets without mice. Captions benefit users in noisy environments. Accessibility improvements are usability improvements — they make the product better for everyone.
❌ Myth: ARIA attributes make a component accessible.
Reality: ARIA communicates roles, states, and properties to assistive technology — it does not add keyboard behaviour or interactivity. A <div role="button"> with an aria-label still won’t respond to Enter or Space, won’t be focusable, and won’t fire click events from a keyboard unless you add all of that manually. The first rule of ARIA is: don’t use ARIA if a native HTML element does the job. A real <button> is focusable, keyboard-operable, and announces itself as a button automatically. ARIA added on top of broken HTML does not fix the HTML.
8 Now You Try
Three graded exercises — spot, fix, then build. Write your answer, run it for AI feedback, then compare to the model answer.
An Revenue NZ myIR login page has the five issues below. For each, name which POUR principle it breaks (Perceivable, Operable, Understandable, or Robust) and one sentence on the harm. (a) the password field has no <label>, only a placeholder; (b) the “Log in” button cannot be reached by Tab; (c) grey help text at 2.5:1 contrast; (d) a custom date picker built from <div>s with role="button" that is never focusable; (e) the form error appears as red text with no aria-live.
Show model answer
(a) No label, placeholder only — UNDERSTANDABLE (form labels must be visible and associated). Placeholder text vanishes once the user types and is not reliably announced, so the user loses track of what the field is for. (Also touches Perceivable.) (b) Button unreachable by Tab — OPERABLE (all functionality must work by keyboard). A keyboard-only user simply cannot log in. (c) Grey text at 2.5:1 — PERCEIVABLE (contrast must be at least 4.5:1 for normal text). Low-vision users and anyone in bright light cannot read the help text. (d) Custom div date picker, never focusable — ROBUST and OPERABLE. A div with role="button" that is not focusable or keyboard-operable is broken for assistive tech and the keyboard; native HTML would have been reliable. (e) Error with no aria-live — PERCEIVABLE / ROBUST. A screen reader user never hears the error because nothing announces the dynamic change; wrap it in an aria-live region (or move focus to it). Mapping issues to POUR is how you explain WHY each is a defect, not just that it is one.
The KiwiSaver provider’s “close” control below is inaccessible. Rewrite it so it works for keyboard and screen-reader users, and say what was wrong.
<div class="close" onclick="closeModal()"><img src="x.png"></div>It only responds to mouse clicks, the image has no alt text, and the div is not focusable.
Rewrite it and explain the fixes:
Show model answer
Rewritten markup: <button type="button" class="close" aria-label="Close" onclick="closeModal()"> <img src="x.png" alt=""> </button> (The icon is decorative, so alt="" plus aria-label="Close" on the button; or use a visually-hidden text span.) What was wrong: - A div is not focusable and not activatable by Enter/Space, so keyboard users cannot reach or trigger it. A native <button> is focusable and activatable automatically. - onclick only fires for mouse/touch; the div had no keyboard handling. - The image had no alt and the control had no accessible name, so a screen reader announced nothing useful. What a screen reader announces after the fix: "Close, button." Focus handling when the modal closes: return focus to the element that opened the modal (not the top of the page), so the keyboard user is not dumped back to the start. First rule of ARIA: prefer the native element — here, a real button removes most of the work.
You have a TransitNZ online licence-renewal form (name, address, date of birth, payment, submit). Design a manual accessibility test pass — no automated tool — that a tester could run in 15 minutes. List the checks, how to perform each, and what a failure looks like. Include keyboard, focus, contrast, labels, errors, and te reo Māori handling.
Show model answer
A 15-minute manual pass for the licence-renewal form: Check 1 (keyboard) — Put the mouse aside and Tab through every field and the submit button; Shift+Tab back; Enter/Space to activate. Failure: any field or control unreachable; a keyboard trap you cannot Tab out of; the date picker that needs a mouse. Check 2 (focus order / ring) — Watch the focus ring as you Tab. Failure: focus ring removed (outline:none); focus order jumps around illogically; focused element looks identical to unfocused. Check 3 (form labels) — Click each label; the cursor should jump into its field. Failure: clicking the label does nothing (not associated); a placeholder used instead of a real label. Check 4 (error messages) — Submit with a missing/invalid field and read the message. Failure: "Invalid input" with no detail; error shown only by red colour; error not linked to its field; nothing announced (no aria-live). Check 5 (contrast / zoom) — Eyeball low-contrast text (confirm with the Colour Contrast Analyser), then set browser zoom to 200%. Failure: text below 4.5:1; layout breaks or content is lost/cut off at 200%. Check 6 (te reo Māori) — Inspect any te reo text. Failure: Māori words not wrapped in lang="mi", so a screen reader mispronounces them in English phonetics. Bonus a senior would add: run the main renewal flow once with NVDA + Chrome to hear how it actually sounds — automation catches only ~30% of issues.
Why teams fail here
- Treating a zero-violation axe run as sign-off — automated tools catch only ~30% of WCAG issues; the other 70% (keyboard traps, focus management failures, incoherent screen-reader announcements) require a human to find.
- Testing keyboard navigation with a mouse still on the desk — the moment something feels awkward by keyboard, the tester reaches for the mouse and the defect goes unrecorded. Keyboard-only testing means the mouse is physically out of reach.
- Skipping accessibility on sprints with no "accessibility stories" — every sprint that changes a UI surface carries accessibility risk, including refactors and component library upgrades. The NZ Government Web Standards apply to the output, not the intent of the sprint.
- Never running a screen reader on their own product — most teams have never heard their application through NVDA or VoiceOver, so they have no mental model of the experience. A single 30-minute demo session with NVDA on the team’s own product catches more issues than a written policy ever will.
Key takeaway
Automated tools are your first filter, not your safety net — until you have sat at a keyboard with the mouse out of reach and heard your own product through NVDA, you have not tested it for accessibility.
How this has changed
The field moved. Here is how Accessibility Testing evolved from its origins to current practice.
Section 508 of the US Rehabilitation Act is updated to include electronic technology. W3C publishes WCAG 1.0. Accessibility testing begins as a government compliance obligation, not a quality discipline.
WCAG 2.0 published — technology-neutral principles replace HTML-specific rules. POUR framework (Perceivable, Operable, Understandable, Robust) becomes the foundation. NZ adopts a national Web Accessibility Standard based on WCAG 2.0.
WCAG 2.1 adds 17 criteria — mobile, low vision, and cognitive disabilities. Automated tools (axe-core, WAVE, Lighthouse) become embedded in CI pipelines. NZ Web Accessibility Standard 1.1 mandates WCAG 2.1 AA for public service websites.
WCAG 2.2 published with 9 new criteria including focus appearance and dragging alternatives. NZ updates to WCAG 2.2 AA requirement. EU Accessibility Act deadline (June 2025) creates international pressure.
Accessibility is a legal requirement in NZ government and a procurement gate in the EU. Teams embed axe-core in CI for automated checks plus manual testing with real assistive technology. WCAG 3.0 is in development — a significant rethink of the conformance model.
Self-Check
Click each question to reveal the answer.
Enterprise reality
Government organisations with mandatory WCAG 2.2 AA compliance across all services
- Accessibility is a compliance gate, not a nice-to-have — sign-off requires documented evidence: axe scan results, keyboard test records, and a named sign-off owner, all retained for audit. A HealthNZ or MBIE delivery manager cannot ship without it.
- Automated scanning (axe-core) runs in CI on every pull request and blocks merge on new violations — but organisations also mandate human review for WCAG conformance because tools catch only ~30% of issues. Both gates must pass before a release is approved.
- Voluntary Product Accessibility Templates (VPATs) and Accessibility Conformance Reports (ACRs) are produced for procurement — government agencies buying software must verify WCAG AA conformance before contract award, so vendors supply a completed VPAT as a tender requirement.
- Dedicated accessibility SMEs (or a centralised accessibility team) review designs before build starts, not after launch — fixing a focus-management failure in a government SPA post-go-live costs 10x what it costs in the design phase, and agencies that have faced Human Rights Act complaints now enforce this as policy.
Q1: Why does the standard mouse-and-eyes happy path miss most accessibility defects?
Because keyboard-only and screen-reader users take paths the sighted, mouse-using developer never exercises. A custom dropdown that only opens on hover, an unlabelled icon button, or an error shown only in red all “work” for the person who built them and lock out the quarter of New Zealanders who interact differently.
Q2: What do the four POUR principles stand for, and why use them?
Perceivable, Operable, Understandable, Robust. They organise every WCAG success criterion, so mapping a bug to a principle lets you explain why it is a barrier (e.g. low contrast is a Perceivable failure; a keyboard-unreachable button is an Operable failure) rather than just citing a rule number.
Q3: What level of WCAG 2.1 is the usual target, and why does it matter in NZ?
WCAG 2.1 Level AA. The NZ Government Web Standards require all government websites to meet AA, so for any public-sector project AA compliance is mandatory; Level A is the floor and AAA is aspirational.
Q4: Roughly how much of accessibility can automated tools catch, and what is the implication?
About 30%. The rest — keyboard reachability, focus management, whether a screen reader announcement is actually useful, whether alt text is meaningful — needs human judgement. Automation is layer one; manual keyboard and screen-reader testing covers the gap.
Q5: Why must te reo Māori text be wrapped in <span lang="mi">?
So a screen reader switches to the correct language voice engine and pronounces the te reo correctly. Without the language tag, Māori words are read with English phonetics and become unintelligible — and te reo Māori is an official language of New Zealand.
Q6: Your team is adding a multi-step application wizard to the Benefits NZ (Benefits NZ) benefit portal. Which accessibility checks are highest priority for this component type, and why?
A multi-step wizard introduces the highest-risk patterns: focus management between steps (does focus move to the new step heading or stay on the previous page?), keyboard operability of every control in each step, error announcements via aria-live when validation fires, and a visible progress indicator that is not conveyed by colour alone. Benefits NZ serves some of the most vulnerable New Zealanders, and an inaccessible benefit application can directly prevent someone from accessing their entitlement. WCAG 2.1 AA is mandatory for all NZ government services, so these checks are not optional — they are acceptance criteria.
Q7: What is the key difference between accessibility testing and usability testing, and when does a defect fall into both categories?
Accessibility testing checks conformance against a defined standard (WCAG 2.1 AA) — it produces pass/fail verdicts against specific success criteria. Usability testing evaluates how efficiently and satisfyingly any user completes a task, with no fixed pass threshold. A defect crosses both when it causes a measurable accessibility failure that also degrades the experience for non-disabled users — for example, a 2.8:1 contrast ratio fails WCAG 1.4.3 (accessibility) and also makes text harder to read in bright sunlight on a phone (usability). On an Revenue NZ or RealMe login form, colour-only error indicators fail accessibility (colour as sole differentiator) and also confuse sighted users who skim fast.
Q8: A developer says "we don't need accessibility testing because we used ARIA roles on all our custom components." What is wrong with this reasoning and how do you respond?
ARIA communicates roles, states, and properties to assistive technology — it does not add keyboard behaviour. A <div role="button"> with an aria-label is still not focusable and will not fire on Enter or Space unless the developer has manually added a tabindex, a keydown handler, and click propagation. The first rule of ARIA is: don't use ARIA if a native HTML element will do the job. A real <button> handles all of this automatically. You would respond by demonstrating the gap live: Tab to the custom component, press Enter, and show nothing happens — then compare to a native button. ARIA added on top of broken HTML does not fix the HTML.
Q9: When is it appropriate to skip accessibility testing on a sprint, and what risk does skipping introduce for a team building a KiwiSaver provider's online dashboard?
Skipping is only defensible when a component has not changed since its last full accessibility audit, or when the release contains only back-end or data-only changes with no HTML rendered to a user. For a KiwiSaver dashboard, skipping on a sprint that touches the investment summary charts, contribution input forms, or fund-switch flow introduces real risk: FMA scrutiny of digital service equity is increasing, and a blind or low-vision member who cannot access their own retirement savings could raise a Human Rights Act 1993 complaint. The pragmatic approach is a lightweight diff-based pass — re-test only changed surfaces using axe DevTools and a keyboard tab-through, not a full re-audit of unchanged pages.
★ Interview Questions
What NZ hiring managers ask about Accessibility Testing — and what strong answers look like at each level.
Q: What is WCAG 2.1 AA and why does it matter for a government project in New Zealand?
Strong answer: WCAG 2.1 AA is the Web Content Accessibility Guidelines at Level AA — the internationally recognised standard that defines what it means for a website or app to be accessible to people with disabilities. In New Zealand it matters because the NZ Government Web Standards mandate WCAG 2.1 AA compliance for all government websites, and the Human Rights Act 1993 prohibits discrimination in the provision of goods and services on the grounds of disability. If you work on an Revenue NZ, CoverNZ, or HealthNZ system and it fails WCAG AA, the agency has real legal exposure.
Grad / Junior
Q: If axe DevTools reports zero violations, can you sign off the page as accessible? Why or why not?
Strong answer: No — automated tools like axe catch roughly 30% of accessibility issues. Zero violations means the mechanical rules pass: labels are present, IDs are unique, ARIA attributes are syntactically valid. It says nothing about whether a screen-reader user can actually navigate the page coherently, whether keyboard focus is managed correctly after a modal closes, or whether the alt text is meaningful rather than just present. On a recent HealthNZ booking form, axe passed cleanly but a screen reader user could not reach the date picker at all because it was a mouse-hover-only custom component.
Junior
Q: A new React single-page application passes every automated check and every keyboard tab-through on individual pages, but screen-reader users report they cannot tell when they have navigated to a new screen. What is happening and how do you test for it?
Strong answer: This is a focus-management failure on route transitions. When the virtual DOM swaps content the browser does not fire a page-load event, so the screen reader does not announce the new page and the user's focus cursor stays wherever it was on the previous view. To test it: open NVDA and Chrome, navigate between routes using the app's own navigation, and listen for a heading announcement at the top of each new screen. If you hear nothing, the SPA is not moving focus to the new page heading after each route change — that is a WCAG 2.4.3 Focus Order failure and needs to be fixed in the router configuration.
Senior
Q: When would you advise a product team NOT to run a full accessibility test pass on a sprint, and what lightweight alternative would you propose?
Strong answer: A full re-audit is unnecessary when only back-end or data-only changes shipped — if no HTML is rendered to a user, WCAG success criteria do not apply. The pragmatic alternative is a diff-based pass: identify which surfaces changed in this sprint and re-test only those using axe DevTools plus a keyboard tab-through of each changed component. For a KiwiSaver provider dashboard this matters because the FMA is increasing scrutiny of digital service equity, so the risk of skipping entirely is real — but spending four hours re-auditing unchanged pages is waste the team cannot justify either.
Senior
Q: A developer argues that adding ARIA roles to all custom components is sufficient for accessibility. How do you respond?
Strong answer: ARIA communicates roles, states, and properties to assistive technology — it does not add keyboard behaviour or interactivity. A <div role="button"> with an aria-label is still not focusable and will not fire on Enter or Space without a manually added tabindex and keydown handler. The first rule of ARIA is: do not use ARIA if a native HTML element does the job. I would respond by demonstrating the gap live: Tab to the custom component in the browser, press Enter, show nothing happens — then swap it to a real <button> and show it works immediately with zero extra code.
Senior
Q: You are the QA lead onboarding a team that has never done accessibility testing before. How do you build the practice into the team's workflow without making it feel like a separate audit bolt-on?
Strong answer: I would start by embedding two lightweight gates into the existing definition of done: axe DevTools passes and a five-minute keyboard tab-through before any story is marked done — that removes the "extra task" framing. Then I would run a 30-minute demo in a team retrospective using NVDA on our own product, because seeing a real user fail to reach a button is more persuasive than any policy document. For measurement I would track axe violation count per release and screen-reader blocking defects per quarter; a downward trend is visible evidence that the practice is working, which makes it easier to defend in sprint-planning trade-offs with the TransitNZ or Revenue NZ delivery managers who are ultimately accountable for WCAG AA compliance.
Lead
◆ What I would do
Professional judgment — when to reach for Accessibility Testing, when to skip it, and what to watch for.
The bottom line: Accessibility testing is not a one-time audit you schedule at the end of a project — it is a set of lightweight gates (axe + keyboard tab-through) embedded into every story’s definition of done, with a deeper screen-reader pass reserved for any sprint that touches interactive components, because that is the only way to catch the 70% of defects that automated tools will never find.
Practice this technique: Try Senior Practice 01 — Accessibility (a11y).
Prerequisites
Related Techniques
What to Learn Next
Also in Bootcamp
↑ Go Deeper
This technique is foundational. Once you understand it, these specialised tracks take you into real-world depth: