The Business Case for Accessibility (Beyond the Lawsuit Risk)

Most accessibility conversations start with fear. “You could get sued.” “The ADA applies to websites.” “WCAG compliance is required.” Those things are real, but they’re a lousy reason to do the work, and fear-based accessibility projects usually produce fear-based results — the bare minimum, box-checked, forgotten about afterward.

There’s a better case for caring about accessibility, and it has nothing to do with lawsuits.

The customers you’re turning away

Roughly 15% of people have some form of disability. Some are permanent — blindness, deafness, limited mobility. Many are temporary — a broken arm, a migraine, a parent holding a baby with one hand. Many are situational — outdoor sunlight on a phone screen, a noisy room where you can’t hear audio, a slow connection where images don’t load.

An inaccessible site isn’t just hard for the “disabled” category — it’s harder for a meaningful slice of your total audience in specific moments. If your checkout process fails for people using a keyboard, you’re losing actual customers. If your video content has no captions, you’re invisible to anyone watching without sound — which, on mobile, is most people.

The business case starts there: accessibility is a conversion optimization strategy disguised as a compliance requirement.

Accessibility work makes everything better

This is the part nobody mentions. The things you do to make a site accessible are, almost universally, things that make the site better for everyone.

• Higher contrast text is easier to read for everyone, especially on phones in sunlight.
• Semantic HTML (headings that are actually headings, buttons that are actually buttons) is easier for search engines to parse. Accessibility and SEO share 80% of their playbook.
• Keyboard navigation is faster for power users who hate mice.
• Captions let people watch your videos in meetings, on noisy commutes, and in bed next to a sleeping partner.
• Clear focus indicators help everyone know where they are on a complex form.
• Descriptive link text (“view our pricing” vs “click here”) helps screen readers and humans equally.

The work pays off in ways you can measure — conversion, bounce rate, time on site — even for users with no disability.

What “accessible enough” actually means

You don’t need to ship a WCAG-AAA-compliant site on day one. You need to hit a reasonable bar (WCAG 2.1 AA is the common benchmark) and avoid the patterns that actively exclude people.

The big ones:

1. Every image has meaningful alt text (or is marked decorative).
2. Color is never the only way to convey information.
3. Text contrast meets the ratio requirements (4.5:1 for normal, 3:1 for large).
4. Everything works with a keyboard — including menus, forms, and modals.
5. Forms have proper labels, not just placeholders.
6. Videos have captions. Audio has transcripts.
7. Headings make sense in order (H1, then H2, not H1 → H4).

A developer who knows what they’re doing can cover most of this in the first pass of a site. It only gets expensive when you retrofit it later.

The retrofit tax

Building an accessible site from the start adds maybe 5% to development cost. Retrofitting an inaccessible one adds 20-40%, because the work touches markup, styles, interactions, and sometimes fundamental design decisions. This is why agencies who care build accessibly by default — they know the alternative is a much bigger bill later.

The uncomfortable part

Accessibility requires a little bit of actual care. Automated tools catch maybe 30% of issues. The rest come from humans using your site and running into friction — a modal that traps focus, a form that doesn’t announce errors, a carousel that auto-advances and can’t be paused.

Nobody wants to hear this, but there’s no magic plugin that makes a site accessible. The “one-click accessibility overlays” that promise to fix everything are, in 2026, widely known to be ineffective at best and actively harmful at worst. They don’t work. Don’t buy them.

What works is a developer who cares, a designer who thinks about contrast and focus, a content writer who considers clarity, and a willingness to test with real users occasionally. That’s it.

Where to start

Run your site through WebAIM’s WAVE tool or the axe DevTools extension. Both are free. Neither catches everything, but they catch the obvious stuff, and fixing the obvious stuff is a surprisingly short road to “good enough for 80% of visitors.”

From there, pick one issue a week. Add alt text. Fix a contrast problem. Add a keyboard-accessible version of a menu. Small, steady, boring work. That’s how accessible sites get made — not in a big compliance push, but in months of little decisions that add up.

Your future customers will thank you. Quietly, without knowing they needed to.

Photo by Eduardo Escalante on Pexels.