If you run a public-facing website for a New Zealand government agency, the Web Accessibility Standard isn’t optional: it requires conformance with WCAG 2.1 level AA. What surprises most teams isn’t the requirement — it’s discovering how much of it can’t be verified by running a scanner. This guide covers what AA conformance actually involves, where automated tools stop, and how to be ready before central monitoring finds the gaps for you.

What the Standard requires

The NZ Government Web Accessibility Standard commits agencies to WCAG 2.1 AA across public web content. AA spans four principles — perceivable, operable, understandable, robust — and in practice that means things like: every interactive element usable by keyboard alone, text contrast ratios met, form errors identified and described, content structured so screen readers can navigate it, and nothing that traps focus or relies on colour alone to convey meaning.

Why automated scans aren’t conformance

Automated tools are genuinely useful — they catch missing alt text, contrast failures, and structural issues quickly, and they belong in your CI pipeline. But industry measurements consistently find automated checks can only evaluate a minority of WCAG success criteria. Whether a page’s heading structure makes sense to a screen-reader user, whether focus order follows meaning, whether an error message actually helps — these need a human, and ideally a human using assistive technology.

Full conformance testing combines three layers: automated scanning for the mechanical criteria, expert manual review against the full criterion set, and hands-on testing with assistive technology — screen readers such as NVDA and VoiceOver, keyboard-only navigation, and magnification. Our accessibility testing service runs all three.

The failures we see most on NZ government sites

• Keyboard traps and broken focus order in modal dialogs and custom components.
• PDF documents published without tags, headings, or reading order — often the largest single source of non-conformance on agency sites.
• Form validation that flags errors visually but never tells a screen reader what went wrong or where.
• Data tables and charts with no programmatic structure or text alternative.
• Third-party embeds — booking widgets, maps, media players — inherited into the page without accessibility assessment.

CWAC: monitoring is already happening

The Government Digital Standards function operates centralised web accessibility checking (CWAC) across agency websites, and results are published. That changes the conversation: accessibility gaps are no longer an internal finding — they’re visible. The pragmatic response is to test to the full standard before publication, fix at source, and treat the automated monitoring as confirmation rather than discovery.

Making it stick

Point-in-time audits decay — every release can introduce regressions. Agencies that stay conformant build accessibility into their definition of done: automated checks in the pipeline, component libraries tested once and reused, and periodic assistive-technology reviews of the highest-traffic journeys. Independent testing matters here for the same reason it matters everywhere in government QA: an assessor with no stake in the delivery timeline will tell you about the failure that the delivery team is incentivised to ship past.

If your agency needs a conformance assessment or wants accessibility built into delivery, talk to us — accessibility is one of the ten software testing services we deliver nationwide.

Frequently asked questions

Does the NZ government require WCAG compliance?

Yes. The NZ Government Web Accessibility Standard requires public service and non-public service agencies in scope to meet WCAG 2.1 level AA for public-facing web content, and centralised monitoring checks published sites against accessibility criteria.

Can I just run an automated accessibility scanner?

Scanners are necessary but not sufficient — they can only evaluate a minority of WCAG success criteria. Full conformance requires expert manual review and testing with assistive technology such as screen readers and keyboard-only navigation.

How often should accessibility be re-tested?

Treat any audit as valid only for the release it assessed. Practical cadence: automated checks on every build, manual review of changed components each release, and a full assistive-technology review of key user journeys at least annually or after major redesigns.