You're Spending 30x More Than You Need To

Every organisation I work with has the same story. They build a product. They launch it. Months later — sometimes years later — someone runs an accessibility audit. The report comes back with hundreds of issues. Now they need to retrofit accessibility into a product that was never designed for it.

The cost of this approach is staggering. And it's almost entirely avoidable.

The Cost Multiplier

Research from IBM's Systems Sciences Institute and NIST (National Institute of Standards and Technology) has established a well-documented pattern: the cost of fixing a defect increases exponentially the later it is discovered in the development lifecycle.

Cost of fixing defects at different stages of development

Stage Discovered	Relative Cost	Example
Design	1x	Add a label to a wireframe
Development	6x	Refactor a component to add keyboard support
QA / Testing	15x	Fix, retest, regression test, redeploy to staging
Production	30x	Hotfix, emergency deployment, customer complaints, potential legal exposure

This applies to all software defects, but it's especially true for accessibility. Here's why: accessibility issues in production don't just cost engineering time. They cost customer trust, legal fees, and brand reputation.

The Legal Reality

In the United States, ADA-related digital accessibility lawsuits have been growing year over year. The numbers are sobering:

• Over 4,000 ADA digital accessibility lawsuits were filed in 2023 alone in the US
• The average settlement cost ranges from $10,000 to $150,000 for small to mid-sized companies, and significantly more for larger enterprises
• The Domino's v. Robles case (2019) established that the ADA applies to websites connected to physical places of business — a precedent that has opened the door to thousands of lawsuits
• In India, the RPwD Act 2016 provides legal grounds for similar actions, and SEBI's recent mandate has made compliance a regulatory requirement for the financial sector

The cost of a single lawsuit can exceed the cost of building accessibility into your product from the start. And a lawsuit doesn't just cost money — it consumes leadership attention, damages your brand, and often results in a consent decree that requires years of ongoing compliance monitoring.

What "Shift-Left" Actually Means

"Shift-left" is a concept from software testing that means moving quality checks earlier in the development process. Applied to accessibility, it means catching and fixing barriers before they make it into code — ideally during the design phase.

Here's what that looks like in practice:

At the Design Stage (Cost: 1x)

• Annotate designs with accessibility requirements. Specify heading levels, focus order, alt text for images, and ARIA states for interactive components. If the designer documents it, the developer implements it correctly the first time.
• Use inclusive design patterns. Build your design system with accessibility baked in. Every button component, every form field, every modal — designed once with accessibility, used everywhere correctly.
• Check colour contrast during design. Tools like Stark and the Figma contrast checker let designers verify contrast ratios before a single line of code is written.
• Design for keyboard navigation. For every interactive flow, document what happens when the user presses Tab, Enter, Escape, and Arrow keys. If you can't describe the keyboard experience, neither can the developer.

At the Development Stage (Cost: 6x)

• Use semantic HTML. This is the single highest-impact practice. Use <button> for buttons, <nav> for navigation, <main> for main content, <h1> through <h6> for headings. Semantic HTML gives you keyboard support and screen reader compatibility for free.
• Integrate accessibility linting. Tools like eslint-plugin-jsx-a11y (for React) and axe-linter catch common issues as developers write code — before the code is even committed.
• Add automated accessibility tests to CI/CD. Run axe-core or pa11y as part of your build pipeline. If a pull request introduces a new accessibility violation, the build fails. This prevents regression.
• Do component-level testing. Test each component in isolation with keyboard and screen reader before integrating it into the page. It's much easier to fix a component in development than a page in production.

At the QA Stage (Cost: 15x)

• Include accessibility in your test plans. Every user story should have accessibility acceptance criteria. "As a keyboard user, I can complete this flow using only Tab, Enter, and Escape."
• Manual screen reader testing. Automated tools catch 30–40% of issues. Manual testing catches the rest. At minimum, test with NVDA on Windows and VoiceOver on Mac/iOS.
• Test with real users. If possible, include people with disabilities in your usability testing. We catch things that even experienced testers miss — because we encounter these barriers every day.

The Business Case

Beyond avoiding costs, there's a strong positive business case for accessibility:

• Market size. Over 1.3 billion people worldwide have a disability (WHO). In India alone, the 2011 Census counted 26 million, with the actual number likely much higher. Add ageing populations with declining vision, hearing, and motor skills, and the addressable market grows significantly.
• SEO benefits. Accessible websites tend to rank better in search engines. Semantic HTML, alt text, proper heading structure, and descriptive link text are all both accessibility best practices and SEO best practices.
• Better user experience for everyone. Captions help people in noisy environments. Keyboard navigation helps power users. High contrast helps people using screens in sunlight. Good accessibility is good design.
• Innovation. Constraints drive creativity. Some of the most impactful technology innovations — voice assistants, predictive text, audiobooks, touchscreens — originated from accessibility research.

What I've Seen Work

In my 16+ years working on accessibility, I've seen organisations take two approaches:

Approach A: Retrofit. Build first, audit later, remediate under pressure. This is the 30x approach. I've worked with organisations that spent months — and significant budgets — remediating issues that could have been prevented with a few hours of design annotation and semantic HTML.

Approach B: Shift-left. Embed accessibility into design, development, and QA from day one. The upfront investment is modest: training for designers and developers, accessibility linting in the IDE, automated checks in the pipeline, and periodic manual audits to catch what automation misses.

The organisations that take Approach B spend less overall. They ship faster because they're not dealing with last-minute remediation sprints. Their products are better because accessibility constraints lead to cleaner, more semantic code. And they avoid the legal and reputational risks that come with inaccessible products.

Where to Start

If you're currently in the "retrofit" mode, here's how to shift left:

1. Train your designers first. They're the ones making decisions that determine whether the product is accessible or not. If the design is wrong, no amount of development effort can fix it efficiently.
2. Add accessibility linting to your development environment. This is a one-time setup that prevents issues continuously. It's the highest ROI investment you can make.
3. Add automated accessibility checks to your CI/CD pipeline. Block builds that introduce new violations. This prevents regression and creates a baseline.
4. Schedule quarterly manual audits. Automated checks are your daily safety net. Manual audits are your comprehensive review. Both are necessary.
5. Assign an accessibility champion in each team. Not a dedicated role — a developer or designer who takes ownership of accessibility within their squad. Train them, support them, and give them authority to flag issues.

The Bottom Line

You can spend 1x now or 30x later. The maths isn't complicated.

Every accessibility defect you catch in design saves your team from a rework cycle in development, a test cycle in QA, and a crisis in production. Multiply that by the hundreds of issues in a typical product, and the cost difference is enormous.

The organisations I work with that take accessibility seriously from the start don't just save money. They build better products, reach more customers, and avoid the kind of legal and reputational risks that keep compliance teams up at night.

If you're ready to shift left and want to understand what that looks like for your organisation, let's have a conversation.