Why web accessibility is important: the business case

How many customers does an inaccessible site lose?

Roughly one in six. The World Health Organization puts significant disability at about 1.3 billion people, 16% of the global population, and that is before counting the broken wrist, the missing glasses, the bright sunlight, the noisy train.

Accessibility features are used far beyond their target population: captions, keyboard shortcuts and high-contrast modes are mainstream conveniences. An inaccessible checkout doesn’t offend these users; it simply loses them. They buy from the competitor whose form works with a screen reader, and no analytics dashboard tells you why.

Do accessible websites convert better?

Yes, through mundane mechanics rather than goodwill. Labelled fields with specific error messages get forms completed, readable contrast keeps people on the page, and adequate target sizes cut mis-taps on the mobile traffic that makes up most sessions.

• Labelled fields with clear error messages (WCAG 3.3.x) are the difference between a completed checkout and an abandoned one, for everyone rather than just screen reader users. “Something went wrong” loses customers; “Card expiry must be in the future” keeps them.
• Readable contrast (1.4.3) keeps people reading on phones outdoors and screens at low brightness, which is a large share of real sessions.
• Adequate target sizes (2.5.8) cut mis-taps on mobile, where most traffic lives.
• Keyboard support keeps assistive-technology users and keyboard-driven power users in the funnel rather than out of it.

What is the legal risk of an inaccessible website?

It varies by jurisdiction but moves in one direction, and every regime converges on the same technical baseline:

• United States: ADA web accessibility lawsuits have run at thousands of filings per year for years, hitting e-commerce hardest. Settlements plus forced remediation under deadline is the expensive way to reach the same destination.
• Europe: the European Accessibility Act applies to e-commerce, banking, transport and more. It reaches the private sector, not just government. EN 301 549 (which incorporates WCAG) is the reference standard.
• Australia: the Disability Discrimination Act has covered websites since Maguire v SOCOG in 2000. Government procurement expects WCAG conformance, and complaints against private organisations succeed.

Every regime converges on the same technical baseline: WCAG AA. Meeting it once answers all of them.

Does accessibility work help SEO?

Substantially, because it is largely the same work. Semantic headings, alt text, descriptive link text, transcripts and captions are simultaneously WCAG requirements and ranking inputs, because search engines read structure rather than pixels and that is the same structure assistive technology depends on.

The overlap is specific rather than total, and worth separating from the overclaiming that surrounds this topic. As answers move into AI experiences, machine-readability compounds: accessible pages are the ones AI systems can quote.

You can fund the accessibility work from the SEO budget with a straight face. It’s the same work.

How much does accessibility cost to retrofit?

Several multiples of what it costs to build in. At design time accessibility is mostly decisions and costs almost nothing; after launch it is archaeology across thousands of pages, usually under a deadline someone else set.

The cost curve is steep in the wrong direction:

• At design time, accessibility is mostly decisions: token contrast, focus states, label placement. Near-zero marginal cost.
• At build time, it’s habits: semantic elements, wired labels, alt text in the CMS workflow.
• After launch, it’s archaeology, often under a legal deadline: auditing thousands of pages, refactoring component libraries, retraining teams.

Industry rules of thumb put retrofit cost at several multiples of build-time cost, and that matches what we see: a component fixed once in a design system fixes a thousand pages; the same fix applied page-by-page after a demand letter is a project.

There’s a quality dividend too. The most common failures are defects by any definition: unlabelled controls, broken heading structure, keyboard traps. Teams that catch them ship better interfaces for everyone.

Why do accessible sites cost less to run?

Because semantic HTML does natively what ARIA-and-JavaScript reconstructions do expensively, and because accessibility failures are ordinary defects that only some users can see.

The accessible way to build a button is <button>. The inaccessible way is a div plus click handlers, key handlers, focus management and ARIA state, shipped as JavaScript and parsed on every load. Multiply that across every disclosure, dialog, menu and tab panel and the pattern is clear: accessible builds lean on the browser, inaccessible builds reimplement it in script. Teams that fix accessibility during a rebuild routinely end up with smaller bundles and faster interaction readiness, not because they optimised but because they deleted reinvention.

Maintenance follows the same logic. A keyboard trap, an unlabelled control or a dialog that drops focus breaks real sessions whether or not anyone files a ticket. Semantic markup is self-documenting, components with defined states are testable, and the defect dies once in the component library instead of shipping forever.

That is why accessibility tracks build quality so closely. An accessible site is one where structure matches meaning, interactions use platform primitives, feedback is explicit, and the team tests beyond the happy path. Those four properties are engineering quality. Accessibility does not create them, it makes them checkable.

How does accessibility win deals?

By clearing a filter your competitors fail. Government, education and enterprise buyers ask for a VPAT/ACR during procurement, and “we don’t have one” reads as “we haven’t thought about this” at exactly the wrong moment.

If you sell software, accessibility is now revenue-side rather than a cost centre. The document itself is a smaller job than most teams expect once the testing exists, since an ACR can be generated from scan data rather than assembled by hand.

How do I make the business case internally?

Run three numbers rather than a moral argument: the revenue attached to the sessions you are degrading, the cost of one demand letter or lost enterprise deal, and the difference between fixing a component now and every page later.

Skip the moral framing if it hasn’t landed; run the numbers that fit your business:

1. Revenue: sessions × 16% × your conversion value = the traffic you’re serving a degraded experience.
2. Risk: one demand letter or failed enterprise deal typically exceeds a year of accessibility tooling and fixes.
3. Efficiency: cost of fixing a component in the design system now vs. every page later.

Then make the first step small: scan your five highest-traffic pages, fix the criticals, and put scanning in the workflow so the fixes stick. Accessibility fails as an annual event and succeeds as a habit. The business case is really the case for the habit.

Frequently asked questions

How many people are affected by web accessibility?

The World Health Organization estimates about 1.3 billion people, roughly 16% of the global population, live with significant disability. Add temporary impairments and situational limitations, and the share of sessions affected by accessibility barriers is far larger.

Does accessibility improve SEO?

Substantially, through overlap. Semantic headings, alt text, descriptive links, captions and fast keyboard-navigable pages are simultaneously accessibility requirements and search signals. The same work moves both.

What is the legal risk of an inaccessible website?

It depends on jurisdiction, but the trend is one-directional. US ADA web lawsuits run at thousands of cases a year, the European Accessibility Act now applies to a broad range of digital services, and Australian organisations face complaints under the Disability Discrimination Act. Remediation under deadline costs far more than building it right.

Do accessible websites convert better?

Yes, through mundane mechanics. Forms with visible labels and clear error messages get completed more often, readable contrast keeps people on the page, adequate target sizes cut mis-taps on mobile, and working keyboard support keeps power users and assistive-technology users in the funnel instead of abandoning it.

Why are accessible websites often faster?

Semantic HTML does natively what ARIA-and-JavaScript reconstructions do expensively. A real button, link or details element ships zero script; a div rebuilt into a button ships event handlers, focus management and state code. Accessible builds tend toward less JavaScript, and less JavaScript is faster.

Where should a team start with accessibility?

Scan your highest-traffic pages, fix the critical automated findings first (alt text, labels, contrast, headings), then add accessibility checks to your development workflow so regressions get caught when they're introduced. Audit-once-a-year is how sites drift back out of conformance.