Most teams say they care about accessibility. Most teams also have an accessibility backlog that hasn’t moved in six months. The gap between those two things is where users get hurt.
Shifting Left
The most important ratio in accessibility isn’t what you think. In fact, you won’t find it anywhere in WCAG. The one that actually drives meaningful outcomes is 16:1 — as in an ounce of prevention is worth a pound of cure. Fixing an accessibility issue in production costs roughly an order of magnitude more than catching it at the design stage. The math isn’t complicated; the discipline is.
Shifting left means treating accessibility as a concern at every phase of the SDLC, not a QA gate at the end:
- Design: Contrast ratios, touch target sizes, and focus indicator styles are design decisions. Catching a contrast failure in Figma costs nothing. Catching it after a component ships costs a redesign, a re-implementation, and a re-review.
- Development: Static analysis (
eslint-plugin-jsx-a11y), automated audits (axe, Lighthouse), and semantic HTML conventions catch a large class of issues before they reach review. These should be part of the definition of done. - QA: Automated tools cover roughly 30–40% of issues. The rest require manual testing — tabbing through flows, running VoiceOver or NVDA, verifying behavior without a mouse. There’s no substitute.
- Production: A clear intake path for accessibility bug reports closes the loop. Issues that reach users get triaged with the same severity logic as any other customer-facing defect.
It’s not tech debt
The most common mistake is treating accessibility issues like tech debt — something internal, something you’ll pay down later. Tech debt is invisible to users. Accessibility issues often aren’t.
If a screen reader user can’t complete your checkout flow, that’s not debt. That’s a broken feature. The fact that it only affects a subset of users doesn’t change the classification — it changes the severity. And severity is something engineers already know how to reason about.
Reframe it: accessibility issues are bugs. They get filed, triaged, prioritized, and fixed like any other customer-facing defect. That framing makes the conversation easier because it plugs into processes that already exist.
Who actually gets affected
The instinct is to picture a narrow group — users who are blind, or who can’t use a mouse. The actual population is much wider than that:
- Blind and low-vision users relying on screen readers (VoiceOver, NVDA, JAWS). A useful mental model: imagine your UI as a phone voice menu. Users navigate linearly, can’t skim, and depend entirely on what gets read aloud. If an element is unlabeled, out of order, or missing context, there’s no visual fallback. Low-vision users may also rely on browser zoom or OS magnification — layouts that break at 200% zoom or use fixed pixel sizes create real barriers.
- Deaf and hard-of-hearing users who need captions or transcripts for any audio or video content. If your product involves telephony, also consider compatibility with the 711 relay service.
- Keyboard-only users — power users, developers, anyone managing RSI. Keyboard-centric navigation is essential for them, but a rising tide lifts all boats: good keyboard support makes every user more efficient.
- Users on slow connections or low-powered devices
- Users in high-contrast or reduced-motion OS modes
- Anyone using a screen in bright sunlight or a noisy environment
- Temporary impairments — a broken arm, eye surgery, a migraine
The curb-cut effect is real. Features built for accessibility tend to improve the experience for everyone. Keyboard shortcuts, clear focus indicators, well-labeled form fields — these aren’t accommodations, they’re just good UI.
The scope argument
If you’re an early-stage startup, move fast — but lean on libraries and frameworks that bake in accessible defaults. Retrofitting accessibility into a mature codebase is expensive. Building on a solid foundation isn’t.
If you’re at scale, the stakes are higher. Roughly 15–20% of the global population has some form of disability. If your product has meaningful reach, that’s not a niche — that’s a segment. And if you’re pursuing federal or state/local government (FED/SLED) contracts, an Accessibility Conformance Report (ACR) — a completed VPAT — is a legal procurement requirement. You can’t get in the door without one.
There’s also direct legal exposure. ADA website accessibility lawsuits alleging violations of Title III have risen sharply — between 4,000 and 8,800 federal suits filed annually in recent years, primarily targeting companies with inaccessible websites. In Robles v. Domino’s Pizza (9th Cir. 2019), a blind plaintiff sued because Domino’s website and app were incompatible with his screen reader. The Ninth Circuit ruled that the ADA applies to websites and apps of businesses with physical locations. The Supreme Court declined to hear the appeal. Domino’s settled. The case established that digital inaccessibility is actionable under Title III — and that “we’ll fix it later” is not a defense.
The annual audit problem
An annual accessibility audit is better than nothing, but it fundamentally misframes the problem — especially for SaaS products.
A SaaS product ships continuously. Features land, components get refactored, dependencies update, design systems evolve. An audit captures a snapshot of accessibility at a single point in time, and that snapshot starts decaying the moment the next PR merges. By the time the next audit rolls around, the gap between “audited state” and “current state” can be substantial.
Worse, a clean audit report creates a false sense of compliance. It doesn’t mean your product is accessible — it means it was accessible enough on the day someone checked. That distinction matters when a user files a complaint or a legal team gets involved.
Audits are also reactive by design. They find problems that already exist in production, which puts you back in the most expensive part of the fix cycle. Treating an annual audit as your primary accessibility mechanism is the opposite of shifting left.
The Rolling VPAT
A Voluntary Product Accessibility Template (VPAT) is the standard document organizations use to communicate how a product conforms to accessibility standards. Traditionally, it’s produced annually — usually to satisfy a procurement requirement — and then left to go stale.
The Rolling VPAT flips that model: publish an updated VPAT with every release or on a much tighter cadence. Each version is tied to a specific release of the software, so the conformance report always reflects the current state of the product. Over time, the version history becomes a record of how accessibility has improved (or regressed) across the product’s lifetime.
The benefits are concrete:
- Accuracy: Customers and procurement teams see conformance data that matches what they’re actually running — not a document from eighteen months ago.
- Accountability: Regressions are visible. If a release introduces a new failure, it shows up in the next VPAT. That visibility creates real internal pressure to treat accessibility issues with the same urgency as other defects.
- Trust: A history of rolling VPATs signals that accessibility is a continuous commitment, not a checkbox exercise. In enterprise sales cycles where an ACR is a procurement gate, that signal matters.
The Rolling VPAT doesn’t replace the continuous process — it’s the artifact that proves the process is working.
The bottom line
Accessibility isn’t a feature you ship once. It’s a quality bar you maintain, the same way you maintain performance or security. The teams that get this right don’t treat it as a separate workstream — they treat it as part of the definition of done.