Website accessibility audits in NZ: get it fixed.

A customer tries to book a job on their mobile phone. The menu button has no label for screen readers. They tap around, get stuck, and leave. You never hear about it - you just lose the enquiry.

That is the practical reason a website accessibility audit matters for Bay of Plenty businesses. Accessibility is not a side quest. It is basic conversion hygiene: can real people complete the task your site exists for?

Website accessibility audit NZ: what you are actually checking

An accessibility audit is not a single tool score, and it is not a one-off “pass or fail”. It is a set of checks against how users with different access needs interact with your site: keyboard-only navigation, screen readers, low vision, colour blindness, cognitive load, motion sensitivity, and plain old small-screen constraints.

In NZ, most organisations aim to meet WCAG 2.1 AA (or WCAG 2.2 AA where practical). Whether you are legally required to hit a specific standard depends on who you are and what you provide. If you are a public sector organisation or do work adjacent to government procurement, expectations are higher. If you are a private business, the risk is less about a formal audit letter and more about excluding customers, damaging trust, and building expensive rework into the site later.

A useful audit answers two questions: what is stopping users completing key tasks today, and what is the lowest-effort route to reducing that friction without breaking the site.

Start with user journeys, not a checklist

If your website generates revenue, there are usually three journeys that matter: calling you, submitting a form, and finding the details to make a decision (service pages, pricing signals, proof, location). An audit should begin there.

For each journey, you test with a keyboard (no mouse) and at least one screen reader workflow. You also test on mobile, because many accessibility failures are simply poor mobile implementation: tiny tap targets, menus that trap focus, and modals that cannot be dismissed.

You can still use automated scanning, but use it for coverage, not conclusions. Automated tools spot patterns like missing alt attributes, low colour contrast, and form labels. They do not understand whether your “Book now” button is reachable in the actual page flow.

The high-impact issues we see on NZ small business sites

Most problems are not exotic. They are the same handful of implementation details repeated across WordPress themes, page builders, and custom sites.

Navigation and focus problems

If you cannot reach the main menu, dropdowns, and call-to-action buttons using the Tab key, users will not complete the job. Common causes are:

• Custom menus built with divs and click handlers only
• Focus styles removed for “clean design”
• Mobile menus that open visually but do not move keyboard focus into the menu
• Popups and cookie banners that trap focus or hide the close control

The fix is usually straightforward: correct semantics, correct focus management, and keep visible focus outlines. If your designer does not like the default outline, style it - do not delete it.

Forms that look fine but fail assistive tech

Forms are where leads are won and lost. The main failures are missing labels, placeholder-only instructions, and unclear error states.

A working form needs proper label elements, sensible field order, and errors that are both visible and announced to assistive technology. If a required field fails validation, the user should be told what went wrong and how to fix it. “Invalid input” is not helpful. “Please enter a phone number, e.g. 021 123 4567” is.

Also check: is the form usable at 200% zoom on mobile? If it breaks layout or hides the submit button, it is not accessible in practice.

Colour contrast and text scaling

Low contrast is still everywhere, especially on light grey text, placeholder text, and buttons with thin outlines. WCAG contrast ratios are measurable, but the business consequence is simpler: low contrast means hesitation and misclicks.

Text also needs to reflow. Users will zoom. If your layout relies on fixed heights, it will clip headings and overlap buttons. This is common in hero sections and fancy cards.

Images, icons, and “invisible” content

Alt text is not about stuffing keywords. It is about making the page make sense without images. Decorative images should have empty alt. Functional icons (phone, location, download) need accessible names. If you use an icon-only button, it must have an aria-label that matches the action.

Also watch for content that exists visually but not semantically. Page builders sometimes produce headings that are styled as headings but coded as generic text. Screen reader users rely on heading structure to navigate.

PDFs and embedded documents

Many NZ businesses post forms, brochures, and price lists as PDFs. If the PDF is not tagged properly, it can be unusable. You can either fix the PDF accessibility or, often better, move critical content into HTML pages and keep PDFs as optional downloads.

This is a trade-off: PDFs are convenient for printing and emailing, but HTML is easier to keep accessible and searchable.

What “good enough” looks like for most SMEs

You do not need perfection to get real gains. A practical website accessibility audit NZ businesses can act on should prioritise the blockers:

1. Users can navigate and operate the site with keyboard only.
2. Forms can be completed, with clear labels and usable errors.
3. Contrast and text resizing do not break content.
4. Core pages have correct headings, link text, and image alternatives.

After that, you tackle the deeper items: skip links, complex widgets, motion settings, and edge-case components.

If your site is heavy on dynamic UI (filtering, accordions, tabs, booking widgets), expect more effort. That is not a reason to avoid accessibility - it is a reason to audit earlier and budget properly.

How to run an audit without turning it into a project stall

Step 1: Define scope in plain terms

Pick the pages and templates that represent your site. For most small businesses: Home, a service page, pricing or bookings, contact, and one form-heavy page. Add any pages with unique components like sliders, popups, calculators, or embedded booking systems.

Also define the “done” target. If you are aiming for WCAG 2.1 AA, say so. If you are aiming for “remove conversion blockers and meet AA on key templates”, say that instead. Clarity prevents weeks of debate later.

Step 2: Run automated scans, then immediately move to manual checks

Automated tools will surface patterns. Use them to build a punch list, then validate with manual testing.

Manual checks that pay off fast: keyboard-only navigation, focus visibility, form completion, zoom to 200%, and screen reader spot checks on key pages.

If you only do one manual test, do this: start on the home page, tab to your main call-to-action, open the menu, reach the contact page, and submit the form without touching the mouse. If you cannot do that cleanly, your users cannot either.

Step 3: Sort findings by impact and cost

Not all issues are equal. “Missing alt text on decorative images” is usually low risk. “Cannot submit form without a mouse” is high risk.

Also be honest about what your platform makes easy. WordPress sites built with a modern block editor and a careful theme are usually fixable without drama. Sites built with multiple page builder layers, injected scripts, and custom widgets can turn simple fixes into ripple effects.

Step 4: Fix at the component level

Avoid page-by-page patching. If every button has low contrast, fix the button styles once. If your heading structure is inconsistent, fix the templates and reusable blocks.

This is where ongoing maintenance matters. Accessibility regressions happen when plugins update, themes change, or someone pastes in a new block that breaks semantics. Treat accessibility like performance: you do not “do it once”, you keep it from slipping.

WordPress and OctoberCMS: what to watch

On WordPress, the usual sources of accessibility debt are themes, page builders, and third-party plugins for popups, sliders, and forms. Choose tools that respect semantics and keyboard interaction. If a plugin’s UI cannot be used with a keyboard, do not expect its front-end output to be accessible either.

On OctoberCMS and other bespoke builds, the risk is often custom components that look clean but ship without proper ARIA, focus handling, or error messaging. The benefit is you can fix the root cause properly once you control the templates.

Either way, accessibility is easier when it is part of your build standards: consistent components, documented patterns, and a simple rule that design choices cannot remove basic usability.

When you should bring in a specialist

If you are dealing with government-aligned requirements, a complex web app, or an internal system that staff rely on, you should treat accessibility as a formal deliverable with proper evidence. That usually means deeper testing, documented outcomes, and sometimes user testing with assistive technology.

If you are a local business site that lives or dies on enquiries, you can still get most of the value with a targeted audit and a disciplined fix cycle.

If you want the audit tied directly to implementation - fixes shipped, re-tested, and kept stable through updates - that is the point of using a web support partner. Talk to Responsive if you need help with tackling your website's accessibility audit..

The trade-offs: accessibility vs speed vs design

You can have all three, but you need to make intentional choices.

Some animation and interaction patterns add friction for motion-sensitive users and complicate keyboard behaviour. Some “minimal” design trends reduce contrast and remove visible focus states. Some performance hacks (like aggressive lazy-loading) can interfere with content order or skip important announcements.

The decision is not “accessibility or aesthetics”. It is whether your design system is built to support real interaction, not just screenshots. If a design choice makes the site harder to operate, it will usually also reduce conversions.

A helpful closing thought: run one accessibility check every time you publish a new page or install a new plugin - not because you are chasing perfection, but because you are protecting the simplest thing your website must do: let people complete the job without getting stuck.