We've just finished a major project for a public health organisation. Over 2,000 pages of content, serving more than a million users a year. Many of those users are in vulnerable situations, accessing mental health resources in moments of crisis. If the site doesn't work with a screen reader, if the navigation can't be operated with a keyboard, if the content isn't structured for assistive technology, those people don't get the help they need. Accessibility isn't a feature for a site like this. It's the entire point.
What You Need to Know
- The NZ Web Accessibility Standard requires all public sector websites to meet WCAG 2.1 AA
- This isn't optional or aspirational. It's becoming a compliance requirement
- Accessibility isn't something you add at the end. It's a design and development practice that runs throughout a project
- The cost of retrofitting an inaccessible site is typically 3-10 times higher than building it right from the start
The NZ Landscape
New Zealand has been moving toward mandatory web accessibility for years. The NZ Government Web Standards require all public sector websites to meet the Web Content Accessibility Guidelines (WCAG) 2.1 at the AA level. This applies to all government departments, crown entities, and organisations delivering public services.
24%
of New Zealanders have a disability
Source: Stats NZ, Disability Survey 2013
Nearly one in four New Zealanders lives with some form of disability. Visual impairments. Motor limitations. Cognitive differences. Hearing loss. These aren't edge cases. They're a quarter of the population.
And beyond permanent disabilities, situational impairments affect everyone. Using a phone in bright sunlight. Navigating a website with a broken mouse. Reading content in a noisy environment. Accessibility improvements help all users, not just those with diagnosed disabilities.
What WCAG 2.1 AA Means in Practice
WCAG can feel intimidating. Dozens of success criteria, technical language, nested conformance levels. Here's what it comes down to in practical terms:
Perceivable
Can users perceive the content? Images need alt text that describes them meaningfully (not "image.jpg"). Videos need captions. Text needs sufficient colour contrast against its background (4.5:1 for normal text, 3:1 for large text). Information can't be communicated through colour alone.
Operable
Can users operate the interface? Every interactive element needs to be reachable and usable with a keyboard alone. Focus order needs to be logical. Links and buttons need visible focus indicators. Users need enough time to read and interact with content. Nothing should flash more than three times per second.
Understandable
Can users understand the content and interface? The language should be clear. Navigation should be consistent. Error messages should explain what went wrong and how to fix it. Form labels should be associated with their fields. The interface should behave predictably.
Robust
Will it work with assistive technology? The HTML needs to be valid and semantic. ARIA attributes need to be used correctly (or not at all, since incorrect ARIA is worse than no ARIA). Custom components need to communicate their role, state, and properties to screen readers.
Lessons From Our Health Project
Building a 2,000-page accessible site taught us things that smaller projects hadn't. Here's what stood out.
Content Structure Is the Foundation
Accessibility starts with content structure, not visual design. Headings need to follow a logical hierarchy (h1, h2, h3 - not randomly chosen based on font size). Lists need to be marked up as lists. Tables need headers. Paragraphs need to be paragraphs, not
<div> elements with paragraph styling.For a site with 2,000 pages, this meant establishing content templates with baked-in structure. Authors couldn't accidentally break the heading hierarchy because the CMS enforced it. Navigation landmarks were set at the template level, not page by page.
Testing With Real Users Changes Everything
We tested with screen reader users. The experience was humbling. Interactions that felt intuitive with a mouse were confusing or impossible with a screen reader. Navigation patterns that looked clean visually created a maze of redundant links when read linearly.
The single biggest improvement we made came from screen reader testing: simplifying the navigation. What was a clear, visual menu with nested dropdowns was an impenetrable wall of links for a screen reader user. We restructured it. Fewer levels. Clearer labels. Skip-navigation links. The visual design barely changed. The screen reader experience transformed.
Automated Testing Catches 30%
Tools like aXe and WAVE are useful. They catch missing alt text, insufficient contrast, and missing form labels. But they can only evaluate about 30% of WCAG success criteria. They can tell you an image has alt text. They can't tell you if that alt text is meaningful. They can tell you a form field has a label. They can't tell you if the label makes sense.
Automated testing is the starting point. Manual testing with keyboards and screen readers is where you find the real problems.
We ran the automated accessibility checker and got a clean pass. Automated tools are the beginning, not the end.
Rainui Teihotua
Chief Creative Officer
The Business Case
Beyond the moral and legal arguments, accessibility has a business case that's hard to argue with.
SEO benefits. Accessible sites are better structured, which search engines reward. Semantic HTML, clear heading hierarchy, descriptive link text, and image alt text all improve search ranking.
Broader audience. 24% of New Zealanders have a disability. An inaccessible site excludes them. For government and public sector organisations, that's a quarter of the people you're supposed to serve.
Reduced legal risk. As the NZ Web Accessibility Standard becomes enforceable, non-compliance carries real risk. Several international jurisdictions have already seen lawsuits. New Zealand is heading in the same direction.
Future-proofing. WCAG compliance generally produces cleaner, more maintainable code. It also prepares you for WCAG 2.2 and whatever comes after.
Getting Started
If you're running a public sector website that isn't meeting WCAG 2.1 AA, here's a practical starting point:
- Audit. Run automated tools across your site to find the obvious issues. Then do a manual keyboard and screen reader test on your top 10 pages.
- Prioritise. Fix the issues that affect the most users first. Broken keyboard navigation, missing form labels, and insufficient contrast are usually the biggest wins.
- Build it into the process. Accessibility shouldn't be a remediation project. It should be part of how you design and develop from now on. Add it to your design reviews. Add it to your QA process. Add it to your component library.
- Test with real users. Find people who use assistive technology and ask them to test your site. The insights are worth more than any automated report.
The standard is here. The expectation is clear. Build for everyone.