NZ Web Accessibility Standard: What Website Owners Need to Know

NZ Web Accessibility Standard: an overview for website owners

The NZ Web Accessibility Standard guides how websites and web apps should work so people with impairments can use them. If you run a New Zealand-facing site, this standard affects how you design, build and maintain content. This article explains what owners need to do, checks to run, common mistakes to avoid and a short action plan you can use this week.

Who should care and why

The standard is aimed at sites used by New Zealanders. Public sector bodies, schools, health services and many organisations that contract with government are expected to meet the standard. Private businesses that want to reduce legal risk, reach more customers and improve usability also benefit from following it.

How the standard is used (practical view)

The technical requirements map to recognised accessibility rules. Organisations usually show compliance by combining automated scans, manual checks and testing with people who use assistive technology. That mix finds different types of issues: automation finds code and contrast errors, manual testing finds keyboard and focus problems, and user testing finds real-world barriers.

Simple compliance model: assess, fix, publish, maintain

Use four steady phases.

• Assess: run an automated scan, a manual checklist and at least one screen reader test.
• Fix: prioritise issues that block access, then fix content and components.
• Publish: create an accessibility statement that lists status, known issues and contact details.
• Maintain: add accessibility to your release process, procurement and training.

Technical areas to check (detailed)

Semantic structure and headings

Use correct heading tags in order. Headings must reflect the logical structure so assistive technology can navigate the page. Avoid using headings purely for visual style.

Images and non-text content

Provide descriptive alt text for meaningful images. For decorative images use empty alt attributes. For complex images like charts, include a short alt and a longer text description nearby or on a linked page.

Forms and labels

Every form control needs a visible label or an accessible name. Group related fields with fieldset and legend where appropriate. Ensure error messages are programmatically associated with the fields they describe.

Keyboard access and focus

All functionality must work with keyboard only. Visible focus indicators must be present. Avoid trapping focus inside components such as modal dialogs.

Colour and contrast

Text must meet contrast thresholds against its background. Don’t rely on colour alone to convey information. Test text at the sizes it appears on screen, not a hypothetical size.

Multimedia

Offer captions for video and transcripts for audio. Provide audio descriptions when visual information is essential. Ensure media controls are keyboard accessible.

ARIA and scripting

Use WAI-ARIA only to fill gaps where native HTML cannot provide semantics. Misused ARIA creates more problems than it solves. Test dynamic updates with a screen reader to confirm live region announcements.

Practical compliance checklist for a single page

• Run an automated accessibility scanner and save the report.
• Tab through the page from top to bottom. Confirm all interactive items are reachable in a logical order.
• Open the page with a screen reader and check headings, links and form labels for clarity.
• Confirm images have correct alt text or are marked decorative.
• Measure contrast for body text and key UI elements.
• Play any video to confirm captions are present and synced.
• Check focus order for modal dialogs and custom widgets.
• Verify error messages are accessible and linked to form controls.

Common mistakes website owners make

• Only running automated scans and assuming the site is accessible.
• Using ARIA to “fix” broken HTML instead of using semantic elements.
• Missing alt text or writing unhelpful alt text such as “image” or “logo” with no context.
• Relying on colour alone to show required fields or validation states.
• Shipping new components without accessibility tests in the release pipeline.

Accessibility statement: what to include

Publish a clear statement on your site. It should explain:

• Which parts of the site you have tested and which you have not.
• Standards or guidelines you use as a reference.
• Known limitations, planned fixes and a date of last review.
• How users can contact you to report barriers or request accessible formats.

Procurement and contracts

When buying websites or components, include accessibility requirements in contracts. Require deliverables such as automated reports, manual test records and a signed accessibility statement from suppliers. Make ongoing checks part of acceptance criteria.

Quick testing plan you can run this week

1. Pick five high-traffic pages: home, contact, top product page, a form, an article.
2. Run an automated scanner on each page and export results.
3. Tab through each page and take notes on focus order and missing focus styles.
4. Open one page with a screen reader (VoiceOver or NVDA) and listen for heading structure and link text clarity.
5. Create a short issue list, prioritise fixes that block access, and schedule them into the next sprint.

When to hire help

Bring in an accessibility specialist for full audits, assisted user testing and remediation of complex interactive components. Hire a tester who regularly works with assistive technologies for real-user feedback. Use a consultant when you need policy documents or procurement templates that reference the standard.

Next steps for owners

Start with a small, repeatable process: scan, manual check, one user test, and an accessibility statement. Add accessibility gates for new features and include training for content editors. Regular checks keep the site compliant as content and code change.

Note: this article explains practical steps and priorities. For official guidance and legal obligations, consult the government guidance documents and legal advice relevant to your organisation.