The Business Case for Accessibility

Most accessibility budgets are approved out of fear. A demand letter arrived, a deadline is close, a buyer asked for something nobody could produce.

Fear works as a funding mechanism. It's a poor basis for scope, because it produces the minimum defensible effort and stops the moment the threat recedes. The organizations that get durable value frame it differently.

Start with the market arithmetic

Roughly one in four adults has some form of disability. Not all of those affect digital access, but the number that do is substantial — and it excludes the far larger group with situational and temporary constraints: a broken wrist, bright sunlight, a noisy room, a slow connection, being 58 and not yet admitting the text is too small.

Whatever the precise figure, it isn't a rounding error. An inaccessible checkout doesn't lose a percentage point of a niche segment.

The accessibility fixes are usability fixes

Look at what conformance actually demands and notice how much of it is just competent interface work:

• Sufficient contrast, so text is readable in sunlight and on cheap monitors
• Labeled form fields, so autofill works and everyone makes fewer errors
• Error messages that say what went wrong and how to fix it
• Full keyboard operation, which power users prefer anyway
• Clear heading structure, which is also what search engines parse
• Captions, which a large share of viewers use with sound on

These aren't accommodations bolted onto a design. They're the things a well-built interface does. Which is why remediation frequently shows up in conversion and support metrics — form completion improves, abandonment drops, calls from people who couldn't finish something online decrease.

The cost curve is the real argument

Here's the number that should drive the decision. Building accessibility in during design costs close to nothing: choosing a compliant palette, specifying focus styles, using semantic components. It's a design constraint, not a work package.

Retrofitting the same requirements into a shipped product costs multiples of that, because the fixes now land in production components, regression testing, and a release schedule. Retrofitting under legal deadline costs more still — you lose the ability to sequence the work, and you pay for documentation and legal coordination alongside the engineering.

Same requirements. Wildly different cost, determined entirely by when you address them.

The procurement reality

If you sell to government, education, healthcare, or large enterprise, accessibility has already become a gate. Buyers ask for a VPAT. Public entities bound to WCAG 2.1 AA increasingly can't buy inaccessible software without creating their own exposure.

For a software vendor, this stops being a values question and becomes a market access question. Deals stall in accessibility review. That's measurable revenue with a named cause.

What to actually put in the request

Lead with the risk if that's what unlocks the budget — but scope against the rest, because it's what makes the work worth doing rather than merely necessary:

• Risk reduction, quantified against your actual obligations and the cost of remediation under duress
• Conversion and completion on the specific flows you're fixing
• Support deflection from people currently calling because they can't finish online
• Market access, especially if procurement reviews are blocking deals
• Cost avoidance on everything you're about to build

The framing that lasts

Organizations that treat accessibility as a compliance project do it once, badly, and again in three years.

Organizations that treat it as a quality standard — part of what "done" means — stop paying for it separately. Their next audit is boring, which is the goal.