Accessibility Basics
One in five people in New Zealand has a disability. If you only test with a mouse and perfect vision, you are missing a fifth of your users.
1 The Hook — Why This Matters
In 2020, a Wellington government agency launched a new benefits portal. The team tested every feature thoroughly: forms submitted, payments processed, notifications sent. They celebrated on launch day.
Within 48 hours, they received 30 complaints. Screen reader users could not navigate past the homepage. Keyboard users could not reach the "Apply" button. Users who zoomed to 200% found the layout collapsed and buttons overlapped. The site worked perfectly for 80% of users and failed completely for 20%.
The fix cost three weeks of emergency remediation. The agency was publicly criticised for ignoring the Web Accessibility Standard, which is mandatory for NZ government sites. Accessibility is not a feature. It is a requirement.
2 The Rule — The One-Sentence Version
One in five people in New Zealand has a disability. Test for them too.
Accessibility testing is not a specialist skill reserved for experts. It is a basic responsibility. Every tester should be able to check keyboard navigation, colour contrast, and zoom behaviour. These are not advanced techniques. They are the minimum.
3 The Analogy — Think Of It Like...
Building a building.
You would not build a public building with stairs only and forget the ramp. You would not install doors too narrow for wheelchairs. The same logic applies to websites. A mouse-only site is stairs-only. A site that breaks when zoomed is a door that is too narrow. Accessibility is the ramp.
Senior engineer insight
The moment that changed how I think about accessibility was watching a real screen reader user navigate a form my team had just "passed" in testing. She moved through it in browse mode, not Tab mode — and the entire structure fell apart, because we had only tested Tab order. WCAG compliance and real-world usability are not the same thing, and automated tools measure neither one. Once you see assistive technology in the hands of an actual user, you stop thinking of accessibility as a checklist and start thinking of it as a discipline.
The most common mistake Grad testers make: running axe, seeing zero errors, and marking accessibility as done — without ever unplugging the mouse or opening a screen reader.
From the field
A central government agency was preparing for compliance with the NZ Web Accessibility Standard. The team ran Lighthouse on every page, fixed the flagged issues, and submitted a self-assessment showing 100% automated pass rate. Three weeks after go-live, a Ministry review found the site failed WCAG 2.2 AA on keyboard focus management — none of the modal dialogs returned focus correctly after close, and the custom date-picker was completely unreachable without a mouse. The automated tools had passed every element in isolation; they could not test interaction flows. The agency had to open a remediation programme that cost significantly more than building it right the first time. The lesson that generalises: an automated scan is a spelling checker — it tells you what is definitely wrong, not what is definitely right.
4 Watch Me Do It — Step by Step
Here is a real NZ example: testing a council services page for accessibility. Follow these steps on every page you test.
Scenario: You are reviewing an Auckland council page that lists local services, includes images, and has a contact form.
- Run an automated scan Use axe DevTools or Lighthouse. These catch missing alt text, invalid ARIA, and low contrast automatically. They do not catch everything, but they catch the obvious errors in seconds.
- Test keyboard-only navigation Unplug your mouse. Press Tab to move through every interactive element. Can you reach every link, button, and form field? Can you submit the form? If not, it is a defect.
- Check focus indicators are visible As you Tab, can you see where you are? If the focus outline is missing or invisible, keyboard users are lost. A focus indicator must be clear on every element.
- Check colour contrast is 4.5:1 minimum Use a contrast checker on text against its background. Light grey text on white often fails. So do orange buttons with white text. If the ratio is below 4.5:1, users with low vision cannot read it.
-
Check alt text on images
Every informative image needs descriptive alt text. Decorative images should have empty alt (
alt=""). A screen reader reading "image_0034.jpg" is a defect. - Zoom to 200% Use Ctrl and + until the page reaches 200%. Does the layout break? Do buttons overlap? Does text become unreadable? Users with low vision rely on zoom. If the site breaks, it is a defect.
| Check | Test | Result |
|---|---|---|
| Automated scan | axe DevTools | Fail — 3 missing alt texts |
| Keyboard nav | Tab through all elements | Fail — skip link missing |
| Focus indicator | Visible on all interactive elements | Pass |
| Contrast | 4.5:1 minimum | Fail — footer text 3.2:1 |
| Alt text | Descriptive or empty | Fail — "DSC0012.jpg" |
| 200% zoom | Layout readable | Pass |
Four defects in six checks. Automated tools caught the alt text. Your eyes caught the contrast. Your keyboard caught the navigation gap. No single method finds everything.
Scenario 2: Accessibility testing of a form with screen reader edge cases.
The same council page has a "Report a pothole" form. The developer added ARIA labels and tested with keyboard only. But a screen reader user running NVDA reads the form field labels in a confusing order:
| Form Field | Expected Read | NVDA Actually Read | Why It Failed |
|---|---|---|---|
| Location input | "Location, edit text" | "Pothole location, group, edit text" | ARIA label-by wrapped extra text |
| Photo upload | "Upload photo, button" | "Image 0034, button" | Missing accessible name entirely |
| Submit button | "Report this pothole, button" | "Submit button" | Label is visual only, not programmatic |
The lesson: keyboard testing and automated scans passed. Screen reader testing found three issues in one form. This is why WCAG requires both automated and manual testing with real users and assistive technology.
5 When to Use It / When NOT to Use It
✅ Do it when...
- A new page or feature is ready for review
- The site serves the NZ public (mandatory by law)
- You are doing a final pre-release check
- You want to find usability issues that affect everyone
❌ Skip it when...
- You are testing back-end APIs with no UI
- The build changed only internal logic
- You already ran a full accessibility audit this sprint
Before you apply this technique, ask:
- Does your app have keyboard navigation or mouse-only interaction?
- Does your app have images, icons, or visual content that relies on sight?
- Do you have access to real assistive technologies (screen readers, keyboard only)?
- Are you serving users in New Zealand or any regulated jurisdiction?
6 Common Mistakes — Don't Do This
🚫 Thinking it is the developer's job
I used to think: Developers write accessible code, so I do not need to check.
Actually: Developers make mistakes. ARIA roles are wrong, labels are missing, and focus management is broken in ways only a user journey reveals. The tester is the safety net. If you do not test accessibility, no one will.
🚫 Only using automated scans
I used to think: If axe passes, the page is accessible.
Actually: Automated tools catch about 30% of accessibility issues. They cannot judge whether alt text is meaningful, whether tab order is logical, or whether a form is usable without a mouse. Automated scans are a start, not a finish.
🚫 Mouse-only testing
I used to think: If it works with a mouse, it works.
Actually: Many users cannot use a mouse. Keyboard navigation is the foundation of accessibility. If you never unplug your mouse, you are not testing for a significant portion of your audience. Tab through everything.
🚫 Trusting your eyes instead of a real screen reader
I used to think: If the alt text reads correctly to me, a screen reader will understand it.
Actually: Screen readers announce text in ways that surprise you. ARIA labels are hidden from you. Focus order might seem logical on screen but be confusing to someone who cannot see the layout. Always test with actual assistive technology like NVDA, JAWS, or Safari's VoiceOver—not just by reading the HTML.
When this technique fails
Accessibility testing fails when you check only a mouse-based experience or rely solely on automated tools. If your build is incomplete, keyboard navigation may not be wired up yet, causing false positives. Testing on an unstable build wastes time; wait until core navigation is stable before checking contrast, alt text, and screen reader compatibility.
7 Now You Try — Interview Warm-Up
Scenario: You are testing a contact form. Spot the accessibility defects in this HTML snippet:
<input type="text" placeholder="Your name"> <input type="email" placeholder="Your email"> <button style="background:#ccc;color:#fff;">Send</button> <img src="map.jpg">
Write down every accessibility defect before revealing the answer.
Defects found:
| # | Defect | Fix |
|---|---|---|
| 1 | Inputs have no labels | Add <label for="..."> elements |
| 2 | Placeholder used as label | Screen readers skip placeholders |
| 3 | Button contrast fails | #ccc on #fff is 1.6:1; needs 4.5:1 |
| 4 | Image has no alt text | Add alt="Map showing our location" |
Tip: Four defects in four lines of HTML. Accessibility issues are often small, structural, and invisible to sighted mouse users. That is why you must test for them deliberately.
Why teams fail here
- Treating an automated scan as a full audit — axe and Lighthouse catch roughly 30% of WCAG failures; the rest require manual testing and real assistive technology.
- Testing only with a mouse — keyboard-only users, switch-access users, and power users who never touch a mouse are invisible in mouse-only test runs, meaning critical navigation gaps ship to production.
- Writing alt text that describes appearance rather than meaning — "blue button" or "logo.png" tells a screen reader nothing useful; alt text must convey the purpose or information the image carries in context.
- Leaving accessibility to the end of the sprint — issues found after build are five to ten times more expensive to fix than issues caught in design; by the time a tester finds a structural ARIA problem, the component is already in twelve places.
Key takeaway
Accessibility testing is not about compliance paperwork — it is about whether a real person with a real need can actually use what you shipped.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Interview Questions
What NZ hiring managers ask about Accessibility Basics at the Grad level.
Q1. What is the minimum colour contrast ratio required by WCAG 2.2 AA for normal body text?
Strong answer: 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). The NZ Web Accessibility Standard 1.2 mandates WCAG 2.2 AA for all public service websites. In practice: use a contrast checker like the WebAIM Contrast Checker on any text before you consider it accessible.
Q2. Name three ways a user who cannot use a mouse might navigate a webpage.
Strong answer: Keyboard navigation (Tab to move between interactive elements, Enter/Space to activate, Escape to close menus). Screen reader with keyboard shortcuts (heading navigation, link lists, landmark regions). Voice control software like Dragon NaturallySpeaking. Testing keyboard navigation yourself — trying to complete a task using only Tab and Enter — is the fastest way to find accessibility barriers.
Q3. What does "alt text" do and when would you leave it empty?
Strong answer: Alt text (the alt attribute on an img element) is read aloud by screen readers and displayed when images fail to load. It should describe what the image conveys in context — not just what it depicts. Leave it empty (alt="") for decorative images that add no information — logos repeated in nav, background textures, divider images. An empty alt attribute tells the screen reader to skip the image. Leaving out the alt attribute entirely is a WCAG failure.
Q1. What is the minimum colour contrast ratio for normal text?
4.5:1. This is the WCAG AA standard and the minimum required by the NZ Web Accessibility Standard. Large text (18pt or 14pt bold) can be 3:1, but normal body text must be at least 4.5:1.
Q2. Why is placeholder text not a substitute for a label?
Screen readers often skip placeholder text, and it disappears when the user starts typing. A proper <label> is visible, persistent, and programmatically associated with the input. Placeholders are hints, not labels.
Q3. What percentage of accessibility issues do automated tools typically catch?
About 30%. Automated scans find missing alt text, invalid ARIA, and contrast failures. They cannot judge meaningful alt text, logical tab order, or usable form flow. You must always pair automation with manual testing.