Writing a business case for accessibility that actually gets funded

A head of engineering at a Series B SaaS company forwarded me her CFO's reply to an accessibility proposal last month. It was three sentences. "Walk me through the cost of doing nothing. If it is smaller than the cost of doing this, we wait. We have other priorities."

The CFO was not being hostile. He was being a CFO. The proposal in front of him was a $40k budget request that opened with "accessibility is the right thing to do" and never put a number on the alternative. Of course it lost. Anything would have lost against that pitch.

This is the document I wish that engineering leader had walked in with. It is the framework we now hand to every customer who asks "how do I get my company to actually fund this." Three columns: cost avoidance, revenue protection, engineering hours saved. Add a row for talent and brand if you want, but the first three are what get the check signed.

Why "the right thing to do" does not pass finance review

Finance teams do not fund initiatives because they are righteous. They fund initiatives because the expected cost of not doing them, weighted by probability, exceeds the budget ask. That is the trade they have to make on every dollar.

This is not finance being cynical. Most internal proposals are weighed against the next four things on the list. If your accessibility proposal sits next to "rebuild the billing system" and "hire two SREs," the question is not whether your case is morally correct. The question is what breaks if you wait two quarters. You need to be able to answer that with specifics.

The pitch that wins is not "we should care about disabled users." It is "here is what the next twelve months look like if we do not fund this, denominated in the same units finance uses for everything else."

Cost avoidance: regulatory, legal, and contractual

This is the column finance reads first. Three things go in it.

Regulatory enforcement. The actual regulations that apply to your business depend on where you operate and who you sell to, but the calendar is no longer hypothetical. ADA Title II's first compliance deadline for state and local governments serving 50,000 or more passed on April 24, 2026 — covered in our ADA Title II writeup. The European Accessibility Act enforcement deadline passed on June 28, 2025; if you sell consumer-facing digital products into the EU, that one applies to you regardless of where your office is. Ontario's AODA has had teeth for years and has been quietly issuing administrative penalties. If your company sells into any of these jurisdictions, "we will look at it next year" is no longer an answer with a known cost.

Demand letters and lawsuits. UsableNet has tracked ADA-based web accessibility lawsuits in US federal court for years; their annual reports show thousands filed per year, with the bulk concentrated in retail, food service, healthcare, and travel. Demand letters — pre-litigation settlement requests — are several times more common. The typical settlement number you will see quoted publicly is the headline; the real cost includes legal fees, internal time, the remediation itself, and, if you are unlucky, a court-supervised monitor. Pull the numbers your own counsel has seen in your sector and put them in the doc.

Contractual exposure. This is the one finance underestimates. If your MSAs with enterprise customers include accessibility representations — and a growing number do — failing a customer's audit can trigger a cure period, a service credit, or a termination right. Pull three of your largest contracts and read the accessibility clause. There is one. Put the dollar value of the customers it covers next to it.

Be honest about probability. You are not promising the company gets sued. You are showing the expected value of the exposure.

Revenue protection: the deals that pause in procurement

If your sales team is selling into government, education, healthcare, financial services, or large enterprises, accessibility is already a procurement gate. It does not always look like one. It looks like a 47-question security questionnaire with three rows about WCAG conformance and a request for a VPAT. It looks like a legal team forwarding a Section 508 attestation form. It looks like a deal that was "almost closed" stalling for six weeks while your sales engineer tries to find anyone in the company who can answer "what is your last conformance audit date."

Most companies have no idea how often this is happening because the deals do not always come back as a flat "no." They get rescheduled. They go to a competitor who answered the questionnaire faster. The way to size this for the business case is to pull your CRM and ask sales engineering: how many deals in the last twelve months had an accessibility blocker in the procurement phase. Then ask how many we won.

We wrote a separate post on how procurement teams actually evaluate accessibility vendors — the questions are getting more specific every quarter. If you cannot answer them in writing, you are gating yourself out of pipeline you have already paid to generate.

The math here is the same as for security questionnaires five years ago. Companies that could not answer them lost deals to companies that could. The accessibility version of that pattern is happening now.

Engineering hours: the hidden tax of after-the-fact remediation

This is the column most teams forget to put in the doc, and it is usually the largest line item over a twelve-month window.

When accessibility is found in a third-party audit and dropped on the engineering team as a ticket dump, the cost is not "fix forty bugs." The cost is: forty tickets, each requiring a developer to load the context of code they did not write, reproduce the issue, learn the relevant WCAG criterion, design a fix, get it reviewed, write a regression test, and ship. The team I described at the top of this post had previously paid for a manual audit. The audit took eight weeks and produced 312 tickets. Their team spent the next quarter and a half on remediation. None of the work was new feature work. None of it was prevented from coming back the next time someone forgot to add an aria-label.

Compare that to catching the same issues in a pull request, when the developer already has the file open and the relevant context loaded. The marginal cost of fixing an accessibility issue in PR review is minutes. The cost of fixing it six months later, after the original author has rotated to a different team, is hours per issue.

The number to put in the doc is: developer-hours per remediation cycle, multiplied by fully loaded developer cost. Get the per-cycle number from whoever ran your last audit; if you have not done one, you can use the public ranges from WebAIM's annual Million analysis, which has consistently reported that the typical top-1M homepage has dozens of detectable WCAG failures. Multiply by your remediation cost per issue. The number will be larger than the accessibility tool budget. That is the point.

This is also where source-code-level tooling versus overlay widgets matters financially. We wrote about the tradeoff between overlay widgets and source code fixes at length; the short version for the business case is that overlay-style approaches do not retire engineering work. Source-level fixes do.

Talent, brand, and the things finance discounts but should not

A separate row, smaller, but worth including. Recruiting senior engineers and designers is more competitive than ever. Many of them have either built accessible products before or have personal reasons to care. "We do not ship inaccessible code" is a real recruiting signal. It does not move the budget line on its own, but it does change how the headcount line is sized.

The brand exposure is harder to quantify and easier to dismiss in a finance review. Add it last, with a paragraph not a dollar figure, and let it be the closing argument rather than the opening one.

How to size the ask

Now you have a numerator. The denominator is the budget request.

Size it in three buckets:

The first is detection — getting an accurate view of where you are today, across both your shipped site and your codebase. This is a recurring cost, not a one-time scan.

The second is remediation — closing the violations the detection step finds. The cheap version is "developer hours." The cheaper version is automation that produces fixes your team can review and merge.

The third is prevention — wiring detection into the workflow so the same violations do not come back next quarter. CI/CD checks on every pull request. A failing build on critical-severity issues. We covered the mechanics in our post on accessibility in CI/CD.

inklu is built to fit those three buckets at one line item. Scans run on the live site and against the codebase. AI-generated fixes land as GitHub pull requests your team reviews like any other change. The same engine runs in GitHub Actions on every PR. Pricing is token-based — Starter at $29/month, Growth at $99/month, Scale at $349/month — so you can right-size the line item to the size of your codebase. The full plan detail is on our pricing page.

When you write the business case, put the inklu line item next to the alternative cost of an annual third-party audit plus your own engineering remediation time. The audit-plus-remediation column will be larger by a factor most CFOs will find surprising. That is the version of the document that gets funded.

What to do this week

If you are the engineering leader who needs to write this doc, the practical sequence is:

Pull the three largest contracts your sales team has signed in the last twelve months and read the accessibility clause. Ask sales engineering how many deals stalled on accessibility in the last twelve months. Run a baseline scan on your production site and your largest codebase to get a count of detectable violations. Multiply that count by your team's average fix-and-review time and your fully loaded developer cost.

You now have four numbers. The business case writes itself from there.

If you want a hand getting the baseline numbers — both the scan count and the remediation-hour estimate — book a demo at inklu.io or email hello@inklu.io. We will run the scans and hand you the numbers you can paste straight into the planning doc.