We ran an accessibility audit on a system we'd built two years ago. It failed. Not spectacularly, but enough to be embarrassing. Colour contrast issues, form labels missing, keyboard navigation broken in three places. We fixed it, but the lesson stuck: accessibility isn't something you add at the end. It's something you build from the start or retrofit painfully.
What You Need to Know
- The NZ Government Web Standards require WCAG 2.0 Level AA compliance for all government web content
- Accessibility requirements apply to any enterprise system that serves government clients or receives public funding
- The most common accessibility failures are also the easiest to prevent: colour contrast, form labels, keyboard navigation, and alt text
- Building accessible from the start costs almost nothing extra. Retrofitting costs significantly more
The NZ Context
New Zealand's government has been clear on this. The Web Accessibility Standard, part of the NZ Government Web Standards, requires all government agencies to meet WCAG 2.0 Level AA. That's not a suggestion. It's a requirement.
For any enterprise team building systems for government clients, and that includes us, accessibility compliance isn't a feature you can scope out. It's a baseline.
1 in 4
New Zealanders have some form of disability
Source: Statistics New Zealand Disability Survey, 2013
But this isn't just about compliance. One in four New Zealanders has a disability. That's people using screen readers, keyboard-only navigation, high-contrast modes, and zoom. If your enterprise system doesn't work for them, you've excluded a quarter of potential users. For internal systems, that might mean an employee can't do their job. For public-facing systems, it means a citizen can't access a service they're entitled to.
What Breaks Most Often
After auditing our own work and reviewing systems built by other teams, the same issues appear repeatedly. They're not complex. They're just overlooked.
Colour contrast
Text that doesn't have sufficient contrast against its background. Light grey on white. Blue on dark blue. It looks fine on a designer's calibrated monitor and fails for anyone with reduced vision, anyone in bright sunlight, or anyone on a low-quality display.
WCAG 2.0 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. There are free tools to check this. There's no excuse for getting it wrong.
Form labels
Every form input needs a label that's programmatically associated with it. Not just visually placed near it. A
<label> element with a for attribute, or an aria-label. Without this, screen readers can't tell users what information a field expects.71%
of homepages had detectable WCAG failures in form labels or inputs
Source: WebAIM Million Report Analysis, 2017
This is the most common failure across the web. It's also the easiest to fix. Every input gets a label. Every time. No exceptions.
Keyboard navigation
Many users navigate using only a keyboard. Tab to move between elements, Enter to activate, Escape to close. If your interface only works with a mouse, those users are locked out.
The most common keyboard failures: dropdown menus that can't be opened with Enter, modal dialogs that trap focus incorrectly (or don't trap it at all), custom components that aren't in the tab order, and no visible focus indicator showing where the user currently is.
Missing alt text
Every image needs alt text that describes its content or purpose. Decorative images need an empty alt attribute (
alt="") so screen readers skip them. The number of enterprise systems we've seen with no alt text on critical images is concerning.How We Build Accessible Now
After our own audit failure, we changed our process. Accessibility isn't a checklist at the end. It's part of how we build.
Design phase. Rainui checks colour contrast during design, not after. Colour choices are validated against WCAG ratios before the palette is finalised. Interactive elements are designed with visible focus states. Form designs include labels as a structural element, not a visual afterthought.
Development phase. Semantic HTML first. Using
<button> for buttons, <nav> for navigation, <main> for main content, and heading levels that follow a logical hierarchy. ARIA attributes where semantic HTML isn't sufficient. Keyboard event handlers alongside mouse handlers.Testing phase. Automated accessibility testing catches the obvious failures: missing alt text, contrast issues, missing labels. We run these as part of our standard test suite. But automated tools only catch about 30% of accessibility issues. Manual testing with a keyboard and a screen reader catches the rest.
Every accessibility improvement we've made has also made the interface clearer for everyone. Better contrast, logical tab order, clear labels - it's the same work as good design.
Rainui Teihotua
Chief Creative Officer
The Business Argument
For government clients, the argument is simple: it's required. Build accessible or don't bid on the work.
For other enterprise clients, the argument is still strong. Accessibility improvements consistently improve usability for all users. Better form labels reduce input errors. Better contrast improves readability. Keyboard navigation makes power users faster.
There's also the legal direction. The NZ Human Rights Act covers discrimination on the basis of disability. As more services move online, the expectation that digital services be accessible is growing. Australia and the UK have both seen legal action over inaccessible web services. New Zealand hasn't had a landmark case yet, but the trajectory is clear.
Getting Started
If you have an existing enterprise system that hasn't been tested for accessibility, start with these three steps:
Run an automated audit. Tools like axe, WAVE, or Lighthouse will catch the low-hanging fruit. Fix everything they find. It's usually colour contrast, missing labels, and missing alt text.
Test with a keyboard. Unplug your mouse and try to complete a core task. If you can't, your keyboard-only users can't either. Fix the tab order, add focus indicators, and make sure interactive elements respond to Enter and Escape.
Test with a screen reader. VoiceOver on Mac, NVDA on Windows. Navigate your application and listen. Does it make sense? Can you complete a task? This is the test that reveals the most, and the one that's done least often.
For new builds, the cost of building accessible from the start is minimal. It's the same HTML, the same CSS, the same development time, just with awareness of who's using it and how. The cost of retrofitting is real. We know because we've done it.
Accessibility isn't a feature to be scoped in or out. It's a standard. Treat it like one.