Accessibility isn't a compliance checkbox, it's a bigger addressable market

Accessibility conversations with clients usually start from a legal risk angle: avoiding an ADA lawsuit, meeting WCAG guidelines. That framing isn't wrong, but it undersells the actual business case. A meaningful share of any audience has some form of visual, motor, or cognitive difference that affects how they use a website, and building for that audience well is also just building a better product for everyone.

We've found that leading with the risk-avoidance framing alone tends to produce minimum-effort compliance, just enough to reduce legal exposure and nothing more, while leading with the market-size framing tends to produce genuinely better product decisions, because the team starts asking whether a feature actually works well for a real, sizable segment of their audience rather than just whether it technically passes an automated checker.

Sufficient color contrast helps someone using a phone outdoors in bright sunlight just as much as it helps someone with low vision. Clear, visible keyboard focus states help power users who navigate faster with a keyboard, not only users of assistive technology. Most accessibility improvements read as general usability improvements once you stop thinking of them as a separate category.

This reframing changes how a design team responds to accessibility feedback in review. A note that reads as "this fails a compliance rule" gets fixed reluctantly and minimally. A note that reads as "a meaningful share of real users will struggle to read this" gets fixed more thoroughly, because it's addressing a product quality issue the team already cares about rather than a checkbox imposed from outside the design process.

An automated scan (tools like axe or Lighthouse's accessibility audit) catches a meaningful share of common issues in minutes, and a focused manual review of the key user flows, checkout, signup, primary navigation, catches most of what automated tools miss. It's a fraction of the cost of a full custom accessibility consultancy and covers the issues most likely to actually affect real users.

We run the automated scan first, specifically because it clears out the easy, high-volume issues, missing alt text, insufficient contrast on obvious elements, before the manual review even starts. That sequencing means the manual review, which is the more expensive part per hour, gets spent entirely on the subtler issues automated tools can't catch, rather than burning expensive manual time on problems a free scan would have found in minutes.

Meeting WCAG AA is a reasonable baseline, not a finish line. Testing key flows with a screen reader, even briefly, surfaces friction that automated tools and static guidelines miss entirely, and it's one of the more eye-opening exercises we run with clients who've never experienced their own site that way.

We usually schedule this as a short, live session with the actual client team present rather than a report handed over afterward, since watching a checkout flow that reads fine visually turn into a confusing, poorly ordered sequence of screen reader announcements is a far more persuasive argument for prioritizing the fix than any written finding would be. Teams that sit through this session tend to treat the resulting fixes as urgent in a way a bullet-point audit report rarely achieves on its own.

Roughly one in four adults in the United States lives with some form of disability, and that number doesn't account for the much larger group experiencing situational or temporary limitations, a broken arm, a bright screen in sunlight, a slow connection that makes heavy animations frustrating rather than merely inaccessible. Framed as an addressable market rather than an edge case, accessibility work stops looking like a cost center and starts looking like a straightforward expansion of who can actually use the product comfortably.

Accessibility considered from the start of a design system, correct semantic structure, sufficient contrast baked into the color palette, focus states designed rather than left as browser defaults, costs very little incremental effort compared to retrofitting it after launch. We treat it as a design system requirement rather than a separate line item, which is both cheaper for the client and more effective, since it means every new page built off that system inherits the accessibility work automatically rather than needing its own separate review.

Retrofitting, by contrast, is genuinely expensive, since it means reopening components that were already considered finished, often across dozens of pages that each need individual review rather than a single systemic fix. We've quoted retrofit projects at multiples of what the equivalent work would have cost baked into the original design system, which is the single most concrete number we can offer a client weighing whether to invest in accessibility now or defer it.

The clients who treat accessibility as a design system requirement from day one, rather than a compliance task bolted on later, consistently end up with a genuinely stronger product, not just a more defensible one. Better contrast, clearer navigation, and more forgiving interaction targets are improvements every visitor benefits from, and the businesses that internalize that connection stop asking whether accessibility work is worth the cost and start asking how quickly it can be built into everything else they're already doing.

It also tends to change how a team hires and reviews work going forward. Once accessibility is understood as a standard quality bar rather than a specialist concern, designers and developers start catching contrast and interaction issues in their own work before a dedicated review ever flags them, which is the point at which accessibility genuinely becomes part of how a team builds rather than a checklist applied at the end of a process built without it in mind, and that shift in habit tends to outlast any single project or audit that first prompted it.