Business case for accessibility
Status: draft
When to use this guide
Leadership, product, legal or sales asks: "Why invest in accessibility when the roadmap is already full?"
The short answer: accessibility is market access, legal risk control, product quality, support cost and trust. It isn't a charitable layer on top of the product. It's whether a person can complete a task in your service without asking someone else for help.
The numbers
WHO estimates that about 1.3 billion people, 1 in 6, live with a significant disability. The CDC reports that more than 1 in 4 adults in the US have some type of disability. Add older users, temporary injuries, bright sunlight and one-handed use, and this isn't an edge audience. It's customers, patients, couriers, employees, and the relatives who help them.
An app changes what a person can do on their own. A delivery app replaces a trip to the store. A banking app replaces a visit to the branch. A health app can be the only way to reschedule an appointment. If that flow is inaccessible, the business loses a conversion and the person loses their independence.
The framing
Verdict: present accessibility as protecting critical tasks, with evidence, not as extra work for a few users.
Why: "extra work for rare users" loses every prioritization meeting. "Users can't pay" doesn't.
The same fix usually helps far more people than the profile it was made for:
| Fix | Also helps |
|---|---|
| Dynamic Type | Older users, long localizations, small screens |
| Captions | Noisy places, sound off, non-native speakers |
| Voice Control names | Hands busy, cooking, driving |
| Focus on the error | Everyone filling a form under stress |
| Gesture alternatives | Tremor, one hand, keyboard, Switch Control |
Business risks
Lost task completion. Analytics shows a drop-off. It doesn't say "VoiceOver focus stayed behind the sheet". If nobody knows whether payment, booking, account recovery and support work with VoiceOver, Larger Text, Switch Control and Voice Control, that's a blind conversion risk.
Support cost. An inaccessible flow turns into support work:
User can't recover from a payment error
Support gets a vague complaint
The agent can't reproduce it with default settings
The bug comes back as low priority
The user leaves
An evidence record shortens that loop.
Legal and procurement. For covered services, accessibility is legal scope: ADA Title II, the Web Accessibility Directive, the European Accessibility Act. Procurement asks for accessibility evidence, conformance reports and vendor acceptance. Legal context without legal theater, Regulatory Evidence Map.
App Store trust. Accessibility Nutrition Labels appear on the product page and tell users whether features like VoiceOver or Larger Text work for common tasks. A label is a claim. When it drifts from reality, trust drops. App Store Label Evidence.
Vendors. A payment SDK, identity verification, maps, chat support or an embedded web view can block a core task. "The vendor owns it" helps neither the user nor the business. Vendor Blind Spot.
Evidence per product area
Area: checkout
Business impact: revenue, support load
Critical tasks: pay, recover a declined card, change payment method
Profiles: VoiceOver, Larger Text AX5, Voice Control
Evidence: transcripts, screenshots, CI audit
Risk owner: payments PM
Release rule: block if payment recovery fails
This turns "accessibility matters" into a decision someone owns.
Metrics worth tracking
critical tasks with current evidence, per profile
blockers per release
time to fix a blocker
App Store labels with evidence older than the last change to their tasks
support tickets tagged accessibility
vendor flows with current evidence
design system components with an accessibility contract
A scanner score is useful, but it isn't a business outcome. Don't track only that.
Executive brief
What changed: checkout redesign
Business risk: payment recovery drives revenue and support load
Accessibility: VoiceOver and Larger Text paths changed
Evidence: VoiceOver pass, Larger Text AX5 pass, Switch Control not checked
Decision: no release until the Switch Control check, or an accessible alternative
One screen, one decision. That's what leadership can act on.
Common objections
| Objection | Answer |
|---|---|
| "We don't have disabled users." | Analytics doesn't label them. They're there. |
| "We'll fix it when someone complains." | Most users leave instead of complaining. |
| "We passed the scanner." | The scanner doesn't complete tasks. |
| "Legal owns accessibility." | Legal interprets the risk. Product owns the task. |
| "It's one epic." | It's a practice and a release gate, like security. |
| "The vendor says it's compliant." | Replay the task. |
Where to go next
Strategy: Chapter 1, Chapter 16.
Release: Evidence Based Release, Testing Evidence Record, Chapter 18.
Law and procurement: Legal context without legal theater, Compliance Theater, Regulatory Evidence Map.