An accessibility business case that gets approved is short, specific to your product, and built on four arguments: how many of your customers it affects, which legal duties already apply to you, what it costs to keep fixing the same problems late, and what you will measure so the spend can be judged later. That's it. You don't need a dramatic ROI multiple or a scary litigation chart. The WHO estimates 1.3 billion people, about 1 in 6 worldwide, live with significant disability (WHO). If you sell into the EU, the European Accessibility Act has applied to in-scope products and services since 28 June 2025. In the US, the Department of Justice says the ADA covers the websites of businesses open to the public. And the cheapest accessibility fix is the one that never ships broken. This guide walks through each argument, the numbers you can honestly cite, and the ones you shouldn't. It also covers the one-page structure I'd hand a CFO.
What goes into an accessibility business case?
W3C's Web Accessibility Initiative groups the case into four arguments: drive innovation, enhance your brand, increase market reach, and minimise legal risk. It also makes a point most internal decks skip: "consideration of the cost and risk of inaction is a critical aspect of any business case" (W3C WAI).
That framing is a good start, but a budget holder wants it translated into your situation. In practice the case needs:
- The problem, measured on your own product (not the internet's average).
- Who it affects among your actual customers and buyers.
- The obligations you already carry, by market.
- The cost of the current approach compared with the proposed one.
- A scoped plan with an owner, a first milestone and a metric.
Points 1 and 5 are what get it approved. Everything in between is supporting evidence.
How many of your customers does accessibility affect?
More than most stakeholders guess, and it's worth starting here because it reframes accessibility as product quality rather than charity.
The numbers you can cite from primary sources:
- Worldwide: about 1.3 billion people, 16% of the population, experience significant disability (WHO, March 2023).
- EU: the European Commission states that 90 million people in the EU live with a disability (European Commission).
- US: the CDC says more than 1 in 4 US adults have some type of disability (CDC).
You'll see "spending power" figures in the trillions quoted everywhere. W3C's own page gives both "more than $6 trillion" and "nearly $7 trillion" in different sections, and doesn't source either inline. I leave those out of internal cases. Once a finance person spots one soft number, they start discounting the hard ones too.
Disability is also not a fixed segment. Ageing customers, someone with a broken wrist using only a keyboard, someone reading your checkout in bright sunlight: they all hit the same barriers. You don't need a statistic for that. Ask a stakeholder to complete your signup flow with the mouse unplugged and they'll understand it in about two minutes.
Which legal obligations should the case mention?
Only the ones that actually apply to you, stated as facts. This is where business cases usually go wrong in the other direction, by leading with fear.
- EU (private sector). The EAA (Directive (EU) 2019/882) applies from 28 June 2025 to in-scope products and services, including e-commerce, consumer banking, e-books, electronic communications and parts of passenger transport. Microenterprises providing services are exempt. National authorities enforce it, and enforcement is still ramping up country by country. Our who must comply with the EAA post covers scope.
- US (private sector). DOJ guidance says "Title III prohibits discrimination against people with disabilities by businesses open to the public" and that inaccessible website features can limit access. It gives businesses "flexibility in how they comply" and points to WCAG as helpful guidance (ADA.gov, March 2022).
- US federal buyers. If you sell software to federal agencies, Section 508 requires each agency to ensure that the technology it develops, procures, maintains or uses is accessible, unless an undue burden would be imposed (29 U.S.C. § 794d). In practice that shows up as a request for your accessibility conformance report. See what a VPAT is.
For a B2B company, that last point is often the strongest line in the whole case. It isn't a risk argument at all. It's a sales argument: an RFP you can answer versus one you can't. Ask your sales team how many security questionnaires came back last quarter with an accessibility section in them.
What does it cost to keep fixing accessibility late?
This is the argument I'd lead with, and it's the one most cases skip.
Most accessibility defects are the same few mistakes repeated through shared code. The WebAIM Million 2026 report found detectable WCAG failures on 95.9% of a million home pages, averaging 56.1 errors per page (WebAIM). Contrast lives in your design tokens. A missing accessible name usually lives in one icon button component, something like <button class="icon-close"><svg>…</svg></button>. Fix the component and every page using it improves.
The expensive pattern looks like this: a yearly audit finds the same categories again, a sprint gets carved out, fixes land, and over the next quarter new features reintroduce half of it. You pay for the same work every year. The cheaper pattern is one remediation pass on shared components, then automated checks in the pipeline so a pull request that drops a label fails before review (accessibility testing in CI).
My opinion, plainly: the cost-of-delay argument does more for accessibility than any lawsuit statistic. Fear gets you one emergency budget line. Showing that you're paying twice for the same fix gets you a process. For how to size that first pass, see how much accessibility remediation costs.
What about SEO and usability, do they belong in the case?
Yes, but as secondary benefits, and without overclaiming.
Some accessibility work overlaps directly with search basics. Google says it uses alt text, "along with computer vision algorithms and the contents of the page", to understand images, and notes that alt text improves accessibility for people who can't see images (Google Search Central). Descriptive headings and link text help both screen reader users and anyone skimming.
What I wouldn't write is "accessibility improves rankings by X%". Google doesn't publish a figure like that, and anyone who quotes one is guessing. W3C's business case cites a single case study where transcripts for a radio show raised search traffic by 6.86% (W3C WAI). That's one podcast, not a forecast for your product. Mention the overlap and let it stay a bonus.
Why shouldn't the case promise compliance?
Because nobody can honestly deliver it from a tool, and a business case that over-promises is the first thing questioned at review time.
Automated testing finds a large share of issues, but not all of them. Deque's analysis of about 2,000 audits found automation covered around 57% of issues by volume (Deque). Counted by WCAG success criteria, the figure is closer to 30%. The rest needs a person: whether focus lands somewhere sensible after a modal closes, whether alt text actually describes the image, whether a screen reader user can finish checkout.
The same applies to shortcut products. In January 2025 the FTC ordered accessiBe to pay $1 million over claims that its widget could make any website WCAG compliant (FTC). If a vendor proposal says "one line of code" and "compliant", that's a reason to reject it, not a cheaper option. More in overlay vs code-first accessibility.
So write the goal as "conformance with WCAG 2.2 AA on our top journeys, verified by automated checks plus manual review", not "become compliant".
What should a one-page accessibility business case look like?
Here's the structure I'd use. It fits on one page, and every line can be checked. The example column shows the shape of each line; fill in your own numbers.
| Section | What to write | Example |
|---|---|---|
| Current state | A measured baseline on your own product | "Scan of signup, checkout and account settings: N root causes, M of them in shared components" |
| Who it affects | Your customers and buyers, with sourced figures | "1 in 6 people worldwide (WHO); accessibility section in N of last quarter's enterprise RFPs" |
| Obligations | Only those that apply, by market | "EAA applies to our EU e-commerce; Section 508 conformance report requested by federal buyers" |
| Cost of status quo | Repeat fixes, lost deals, support load | "Same contrast and labelling findings in the last two audits" |
| Proposal | Scope, owner, first milestone | "Fix shared components in Q1; add CI checks; manual test of checkout with NVDA" |
| Metric | What you'll report next quarter | "Root causes open on top journeys; new regressions blocked in CI; RFP questions answered" |
The baseline row is the one that makes it real. Running a scan on three or four key journeys, including logged-in steps, takes an afternoon. Then track what the scan can't decide with a WCAG checklist. A case built on your own numbers is much harder to wave away than one built on industry averages.
Frequently asked questions
What is an accessibility business case?
An accessibility business case is a short internal document that justifies spending on accessibility by showing who it affects, which legal obligations apply, what the current approach costs and how results will be measured. W3C groups the arguments into innovation, brand, market reach and legal risk.
What is the strongest argument in an accessibility business case?
For most teams it's the cost of fixing the same issues late, measured on their own product. For B2B companies selling to government or enterprise buyers, the ability to answer accessibility questions in RFPs and provide a conformance report is often just as strong.
Should an accessibility business case include lawsuit statistics?
It should state the legal obligations that apply to you as facts, such as the EAA for in-scope EU services or ADA Title III for US businesses open to the public. Leading with fear tends to produce a one-off fix rather than a lasting process.
Can I promise stakeholders that a tool will make us compliant?
No. Automated tools find roughly 30 to 57% of accessibility issues depending on how you count, and the rest needs manual review. Write the goal as verified conformance on your key journeys, not as a tool outcome.
Does accessibility improve SEO?
Some accessibility work overlaps with search basics. Google uses alt text to understand images, and clear headings and link text help everyone. There is no published ranking uplift figure, so treat SEO as a secondary benefit.
Start with your own baseline
The fastest way to make the case concrete is a number from your own product. Run a free scan on the journeys that matter most to your revenue, group the findings by component, and put the count of root causes in the first row of your one-pager. The manual half still needs a person, and the case should say so.
Pavel Charkasau, founder, wcagc.com. Last updated 1 November 2026.
Sources
- The Business Case for Digital Accessibility, W3C WAI — published 9 November 2018, updated 15 July 2024; arguments: innovation, brand, market reach, legal risk; "Consideration of the cost and risk of inaction is a critical aspect of any business case"; transcript case study with search traffic up 6.86%. Accessed 1 November 2026.
- Disability fact sheet, World Health Organization — 7 March 2023; an estimated 1.3 billion people, 16% of the world's population, experience significant disability. Accessed 1 November 2026.
- Union of Equality: Strategy for the rights of persons with disabilities 2021–2030, European Commission — "90 million people in the EU live with a disability". Accessed 1 November 2026.
- Disability impacts all of us, CDC — "More than 1 in 4 U.S. adults have some type of disability." Accessed 1 November 2026.
- Directive (EU) 2019/882 (European Accessibility Act), EUR-Lex — scope (Article 2), application from 28 June 2025, microenterprise exemption for services. Accessed 1 November 2026.
- Guidance on Web Accessibility and the ADA, U.S. Department of Justice — 18 March 2022; Title III covers businesses open to the public; flexibility in how to comply; WCAG as helpful guidance. Accessed 1 November 2026.
- 29 U.S. Code § 794d (Section 508), Legal Information Institute — federal agencies developing, procuring, maintaining or using electronic and information technology must ensure it is accessible, unless an undue burden would be imposed. Accessed 1 November 2026.
- The WebAIM Million: the 2026 report, WebAIM — data collected February 2026, updated 30 March 2026; detectable WCAG 2 failures on 95.9% of home pages; 56.1 errors per page on average. Accessed 1 November 2026.
- Automated testing study identifies 57% of digital accessibility issues, Deque — 10 March 2021; about 2,000 audits, over 13,000 pages, nearly 300,000 issues; about 57% of issues by volume covered by automated testing. Accessed 1 November 2026.
- Google image SEO best practices, Google Search Central — Google uses alt text along with computer vision and page content to understand images. Accessed 1 November 2026.
- FTC order requires online marketer to pay $1 million for deceptive claims that its AI product could make websites compliant, FTC — 3 January 2025; accessiBe. Accessed 1 November 2026.