Building a business case for accessibility

Accessibility business cases fail for a predictable reason: they argue for a standard rather than for a task. A board asked to approve “WCAG 2.2 AA conformance” is being asked to approve something it cannot picture, price or judge.

The ones that succeed name a job somebody cannot finish, and what it costs that they cannot finish it.

Start with a task, not a standard

Name something specific. Can people submit the application, manage the account, read the statement, complete the purchase? Say who is affected and what happens to them when it fails.

Use the evidence you already have — evaluation findings, support tickets, user feedback, what the service team knows. That establishes where you are starting from, which is also what you will measure against later.

Connect it to what the organisation already cares about

Accessibility work competes with everything else for the same budget, so tie it to priorities that are already funded:

• Customer and employee access — people completing important tasks without having to ask for help.
• Delivery quality — finding barriers, assigning fixes, and checking they worked.
• الشراء والتعاقد — naming the standards suppliers must meet and the evidence you will accept.
• Team capability — the skills that stop the same issues being rebuilt next quarter.

Pick the ones that fit your market. For UAE delivery, include the national accessibility policy and Design System requirements; where Section 508 or EAA obligations apply, keep them distinct from the technical WCAG assessment. Define the standards and compliance scope before estimating anything.

Give decision-makers something they can judge

A proposal they can assess connects one defined problem to one bounded piece of work. It should say:

• The service or journey, who is affected, and what evidence you have.
• The work proposed, what it produces, and who is responsible.
• The dependencies — supplier access, release dates, anything outside your control.
• How findings will be prioritised, implemented and verified.

Separate the cost of understanding the problem from the cost of fixing it. An assessment can tell you the scope of the remediation; it cannot remove every unknown before the work begins, and a proposal that pretends otherwise will be wrong in public later.

Choose measures that survive scrutiny

A count of issues tracks a backlog. It does not tell you whether the service got better, and it misleads in both directions: several findings often describe one component, while a single issue can block an entire task.

Pair any progress number with the things that give it meaning — severity, which journeys are affected, and how much of the service was actually reviewed. Then agree when you will look again, and ask three questions:

• Have the important fixes been verified, rather than reported as done?
• Are new releases repeating the same patterns?
• Do the teams now have the guidance to avoid them?

That gives the next investment decision something to stand on. A headline score does not.