Last year I wrote about the accessibility imperative for government sites. That was about compliance. This is about something broader: how enterprise teams in New Zealand should be thinking about accessibility as a design practice, not just a checklist. The standards are evolving. The expectations are rising. And the gap between what most enterprise software delivers and what accessible software looks like is still significant.
What You Need to Know
- The NZ Web Accessibility Standard applies to all public sector web content and is increasingly expected in private sector enterprise software
- WCAG 2.1 AA is the benchmark. It covers perceivable, operable, understandable, and robust content
- Accessibility is a design and development practice, not a testing phase. Retrofitting is 3-10 times more expensive than building it in
- Real accessibility testing requires assistive technology and real users, not just automated scans
The NZ Context
New Zealand's Web Accessibility Standard requires all public sector websites and web applications to meet WCAG 2.1 at the AA conformance level. This isn't aspirational. Government agencies procuring digital services increasingly include accessibility requirements in their RFPs, and non-compliance is a disqualification criterion.
The private sector is moving more slowly, but the direction is clear. The NZ Human Rights Act prohibits discrimination on the basis of disability, and as more services move online, the expectation that those services are accessible is growing. Several international jurisdictions have seen legal action against private organisations for inaccessible web services. It's reasonable to expect NZ will follow.
1.1M
New Zealanders living with a disability
Source: Stats NZ Disability Survey, 2013
Beyond the legal and compliance argument, there's a straightforward user argument. Over a million New Zealanders live with some form of disability. In enterprise contexts, that means a meaningful percentage of your users have accessibility needs. Ignoring them isn't just non-compliant. It's bad product design.
Building Accessibility In
1. Start with Semantic HTML
The most impactful accessibility practice is also the simplest: use HTML elements for their intended purpose. Headings for headings. Buttons for actions. Links for navigation. Lists for lists. Labels for form fields.
Screen readers and other assistive technologies rely on semantic HTML to understand page structure. A
div with an onClick handler looks like nothing to a screen reader. A button element is announced as interactive, receives keyboard focus, and responds to the Enter and Space keys automatically.This sounds basic. In practice, I see enterprise applications built almost entirely from unsemantic
div elements with JavaScript event handlers. The result looks fine visually but is completely opaque to assistive technology.2. Design with Contrast and Colour
Colour contrast isn't just about aesthetics. WCAG 2.1 AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. This matters more than most designers realise.
Enterprise interfaces often use light grey text on white backgrounds for secondary information. That's a contrast failure. They use colour alone to indicate status (red for error, green for success). That fails for the roughly 8% of men with colour vision deficiency.
Design with contrast from the start. Use tools like the WebAIM contrast checker during the design phase, not as a post-build audit. And never rely on colour alone to convey information. Pair colour with text labels, icons, or patterns.
3. Build for Keyboard Navigation
Every interactive element in an enterprise application needs to be reachable and operable with a keyboard alone. Tab to navigate. Enter or Space to activate. Escape to dismiss. Arrow keys to navigate within components.
This matters beyond screen reader users. Power users in enterprise applications frequently prefer keyboard navigation for speed. Motor impairment users may use keyboard alternatives or switch devices. And anyone with a broken mouse needs keyboard access as a fallback.
Test keyboard navigation by putting your mouse in a drawer and trying to complete a task. Every point where you get stuck is an accessibility barrier.
4. Write Meaningful Alt Text and Labels
Every image needs alt text that describes its content or purpose. Every form field needs a visible label. Every icon-only button needs an accessible name.
For enterprise data interfaces, this extends to charts and visualisations. A chart that conveys critical business information needs a text alternative that communicates the same insight. Not "bar chart" but "Revenue trending upward, 12% growth quarter over quarter."
5. Handle Dynamic Content
Enterprise applications are dynamic. Notifications appear. Modals open. Content updates after form submissions. Assistive technology users need to be informed when content changes.
ARIA live regions announce dynamic updates to screen readers. Focus management ensures that when a modal opens, keyboard focus moves to the modal and returns to the trigger when it closes. Status messages after form submissions are announced without requiring the user to navigate to them.
Accessibility in enterprise isn't about edge cases - it's about building software that works for everyone who needs to use it.
Rainui Teihotua
Chief Creative Officer
Testing Accessibility
Automated Scans Are a Starting Point
Tools like axe, WAVE, and Lighthouse catch roughly 30-40% of accessibility issues. They're useful for catching low-hanging fruit: missing alt text, contrast failures, missing form labels. Run them in CI so regressions are caught automatically.
But automated tools can't tell you whether alt text is meaningful, whether keyboard navigation is logical, or whether dynamic content is announced appropriately. They check syntax, not experience.
Manual Testing Is Essential
Keyboard testing (put the mouse away), screen reader testing (VoiceOver on Mac, NVDA on Windows), and zoom testing (200% and 400% magnification) catch the issues automated tools miss. Build these into your regular testing process, not just a pre-launch audit.
Real User Testing Is Best
If possible, include users with disabilities in your enterprise user testing sessions. Their feedback will reveal barriers that neither automated nor manual testing surfaces, because they encounter those barriers in the context of real tasks with real urgency.
The Investment Argument
The cost of building accessibility in from the start is marginal. Semantic HTML, proper contrast, keyboard navigation, and meaningful labels add modest time to the design and development process.
The cost of retrofitting accessibility into an existing enterprise application is significant. Restructuring HTML for semantics, adding keyboard support to custom components, fixing colour contrast across an entire design system, and adding ARIA attributes throughout a codebase is weeks to months of work.
Build it in. It's cheaper, it's better for your users, and it's increasingly a requirement.