We lost a government contract in 2019 because our client's existing system didn't meet WCAG 2.1 AA. The RFP required it. The system was three years old, well built, and well liked by its users. It failed the accessibility evaluation, and the contract went to a competitor whose product was demonstrably worse in every other dimension but ticked the compliance box. That's when Isaac and I stopped framing accessibility as "the right thing to do" and started framing it as "the thing that wins and keeps contracts."
What You Need to Know
- 24% of New Zealand's population lives with a disability. In a 500-person organisation, that's roughly 120 people
- NZ Government Web Accessibility Standard requires WCAG 2.1 AA for all public-facing government services
- Accessible software has measurably lower support costs because fewer users need workarounds
- Accessibility constraints produce better design decisions, improving the experience for all users
- The cost of building accessibility in from the start is 5-10x lower than retrofitting it later
The Numbers
Let's start with the market size, because this is the part that gets boardroom attention.
1.1 million
New Zealanders live with a disability
Source: Stats NZ, Disability Survey, 2013
That 2013 survey is the most recent full-population data we have. The real number in 2022 is higher, given population growth and an ageing demographic. The point is this: we're not talking about a small niche. One in four adults. That's not an edge case you can defer. It's a quarter of your user base.
For enterprise software, the calculation is different from consumer products. Your users don't choose your software. It's mandated. They use it because their employer requires it. If the software is inaccessible, they can't switch to an alternative. They either struggle through it, develop workarounds, or escalate to IT support. All three cost money.
The Support Cost Argument
Inaccessible software generates support tickets.
A screen reader user who can't navigate a table raises a ticket. A user with low vision who can't read the light grey text on a status card raises a ticket. A user with a motor impairment who can't use the drag-and-drop interface raises a ticket. Each ticket takes time to resolve, and the resolution is usually a workaround, not a fix.
We tracked support tickets for one of our enterprise clients over six months. Of the tickets categorised as "usability issues," roughly 40% were accessibility failures. Missing keyboard navigation, insufficient contrast, form fields without visible labels, interactions that required a mouse. The users didn't describe them as accessibility issues. They described them as "I can't do my job."
Each workaround created by the support team had a maintenance cost. When the software updated, the workaround sometimes broke. The cycle repeated. The client was paying for ongoing support to manage problems that would have been prevented by building accessible software in the first place.
The calculation is straightforward. If accessibility prevents 40% of usability support tickets, and each ticket costs an average of $80 in support time (our client's internal figure), the annual savings on a system generating 300 usability tickets per year is around $9,600. That's not transformative. But it's recurring, it compounds as the user base grows, and it doesn't account for the indirect cost of frustrated employees.
The Adoption Argument
Enterprise software has an adoption problem that nobody talks about honestly. Organisations buy tools, mandate their use, and then discover that actual adoption is 60-70%. People find workarounds. They keep using the old spreadsheet. They ask a colleague to enter data on their behalf.
Inaccessible software makes this worse. If 24% of your workforce has some form of disability, and your software doesn't accommodate their needs, you've structurally excluded up to a quarter of your users from full adoption. Some will push through. Some won't.
We've seen this pattern repeatedly with enterprise portals. Usage analytics show 500 registered users and 340 active users. When you investigate, the gap isn't disengagement. It's inability. Users who found the interface too difficult to use with their assistive technology. Users who couldn't read the low-contrast text. Users who couldn't navigate the complex form with keyboard alone.
Fixing the accessibility issues on one client portal increased active monthly users by 14% within two months. No feature changes. No workflow changes. Just making the existing features usable by people who'd previously been unable to use them.
The Contract Argument
This is the one that moves procurement decisions.
The New Zealand Government Web Accessibility Standard mandates WCAG 2.1 Level AA conformance for all public-facing web content and web applications. Government agencies are required to meet this standard, and they increasingly include it in RFP evaluation criteria.
That means if you're selling software to government, WCAG compliance isn't optional. It's a gate. You either meet the standard or you're excluded from the evaluation. The 2019 contract we lost taught us this lesson. The competitor won not because their product was better, but because ours didn't meet a mandatory requirement.
Private sector organisations are following. Large corporates with government contracts apply the same standards to their internal tools. Insurance companies, infrastructure firms, and education providers are adding accessibility requirements to their procurement processes, partly because of legal obligation and partly because their own workforce includes people with disabilities.
If you're building enterprise software in New Zealand, WCAG compliance is becoming a market access requirement.
The Design Quality Argument
This is the argument that gets the least traction in boardrooms but matters most to product quality. Accessibility constraints make design better.
When you require sufficient colour contrast, you stop using the decorative light greys that look elegant in Figma and unreadable on a cheap monitor. Your interfaces become clearer for everyone.
When you require keyboard navigation, you simplify interaction patterns. Complex multi-step hover interactions become direct button actions. The interface becomes faster for power users, not just accessible for keyboard users.
When you require clear heading hierarchy, your pages become scannable. Information architecture improves because you're forced to think about structure, not just visual layout.
When you require visible focus indicators, you make the interface legible for keyboard and mouse users alike. People know where they are. They navigate with confidence.
Every time we've applied accessibility constraints to a project, the end result has been better software for every user - not just more accessible, but clearer, faster, more logical. The constraints force good design decisions you might otherwise skip.
Isaac Rolfe
Managing Director
The Cost of Retrofitting
Building accessibility in from the start adds roughly 5-10% to development time. That's our experience across a dozen enterprise projects. It's mostly upfront, in the design system and component architecture. Once the foundation is accessible, individual features inherit that accessibility with minimal extra effort.
Retrofitting accessibility onto an existing system costs 5-10x more. You're not just fixing individual elements. You're often re-architecting components, restructuring page layouts, refactoring forms, and rewriting custom interactive elements. You're doing this while maintaining the existing functionality, which constrains your approach.
We've done both. Building it in is cheaper, faster, and produces better results. Retrofitting is painful, expensive, and often incomplete because the budget runs out before every issue is resolved.
Making the Case Internally
If you're trying to get accessibility funded in your organisation, frame it around business outcomes, not moral obligation.
For the CFO: Accessible software reduces support costs and increases user adoption, both of which have measurable financial impact. Retrofitting later costs 5-10x more than building it in now.
For the sales team: WCAG compliance opens government and large enterprise contracts. Non-compliance excludes you from evaluations. This is revenue at risk.
For the CTO: Accessibility is engineering quality. The same discipline that produces tested, documented, well-structured code produces accessible code. It's not a separate workstream. It's part of building well.
For the CEO: 24% of your customer's workforce has a disability. Building software that excludes them is a product decision with commercial consequences.
The moral case for accessibility is real and it matters. But in our experience, the moral case alone doesn't get budget approval. The business case does. Once the work is funded, the team discovers that building accessible software is better engineering, better design, and better product management across the board.