There are two sentences you hear in almost every planning meeting about known accessibility issues. The first is, "we'll fix it during the redesign next year." The second is, "let's just patch the worst issues now and revisit the rest later." Both sound like reasonable, budget-conscious decisions. Both get written into a roadmap with a shrug and a note to circle back.
Neither one is free. In fact, the first option, the one that feels the most fiscally responsible on a spreadsheet today, is very often the most expensive path available. Not because redesigns are expensive in general, but because of something software economics has understood for decades: the longer a known defect sits unfixed, the more it costs to fix.
That is not a scare tactic. It is a documented cost curve, and it applies to a missing form label or a broken focus order exactly the way it applies to any other software defect.
The Stat: Widely cited software-engineering research on defect cost curves, most associated with Barry Boehm's analysis of software economics, found that fixing a defect after release can cost 5 to 10 times more than catching the same defect during design or early development. (Source: Barry Boehm, software defect cost curve research)
An Unfixed Accessibility Issue Is a Stored Defect, Not a Static One
Boehm's curve was built from decades of software project data, not from anything accessibility-specific. But a WCAG failure is still a defect in the ordinary software sense: a piece of the product that does not do what it is supposed to do. A button with no accessible name, a modal that traps keyboard focus, an error message a screen reader never announces. Each one behaves exactly like the defects in Boehm's research, which is the point.
The reason the curve rises is not mysterious. A defect caught at the design stage costs almost nothing, because nothing has been built around it yet. A defect caught during QA costs more, because code now has to be reopened, retested, and re-reviewed. A defect caught after launch costs the most, because by then it is load-bearing. Other components have been built on top of it, other developers have copied its pattern, and fixing it now means touching live, dependent, already-shipped work instead of a clean draft.
Accessibility issues follow that same shape, with one twist that makes the curve even steeper in practice: they tend to be repeated patterns, not isolated bugs.
Why "We'll Fix It During the Redesign" Quietly Doubles the Bill
Here is the part that does not show up on the roadmap slide. A single unlabeled input field is a five-minute fix in isolation. But that same input pattern usually lives in a shared component, and a shared component gets reused across a checkout flow, a signup form, a settings page, and a dozen other places before anyone circles back to it.
Wait a year, and you are no longer fixing one input. You are fixing every instance of it, across every page it got copied into, plus every new page built on top of it in the meantime. The original fix did not get more expensive because the code changed. It got more expensive because the surface area changed. That is the multiplier hiding inside "we'll fix it later."
There is a second, quieter cost sitting next to that one: context. The developer who wrote the original component, and who could have fixed the issue in minutes because they still held the whole thing in their head, has moved to a different project. Whoever picks up the fix a year later has to relearn the component, trace where it is used, and re-test each instance individually, because nobody is confident anymore that the fix behaves identically everywhere it shipped. Relearning costs real hours, and none of those hours existed when the fix was cheap.
And a known, unfixed accessibility issue does not sit quietly while you wait. It keeps excluding users every single day it stays live, and it keeps sitting there as exposure. We have written separately about what a lawsuit actually costs once that exposure turns into a legal claim, and that is a real, distinct risk worth understanding on its own terms. This article is about a narrower, more certain cost: the remediation itself getting more expensive, with no lawsuit required, purely because of how software degrades and compounds while nobody touches it.
Why "Doubles" Is the Conservative Number, Not the Real One
The title of this piece says waiting doubles the cost. Boehm's research says the real multiplier is 5 to 10 times. That gap is deliberate, not an error.
Doubling is presented here as a floor: the smallest, most defensible estimate of what delay costs, even before you count the compounding pattern-reuse effect above, the context-loss effect, or the accumulated exposure sitting in the meantime. The honest range, based on the cited research, runs meaningfully higher than double. If your organization is budgeting "fix it later" at 1x the current cost, plus a little inflation, you are budgeting for a number well below even the conservative floor.
This is exactly why "patch the worst issues now" and "fix it all during the redesign" are not opposites. They are two different points on the same curve, and the further right you sit on that curve, the more the same fix costs.
A Simple Framework for Deciding When to Act
You do not need a full audit to start applying this. Three questions get you most of the way there:
Is the issue in a shared, reused component? If yes, its cost is compounding right now, every time that component ships on a new page. Fix it at the source before it multiplies further.
Is the person who understands this code still around? If yes, that is a cost discount that expires. Capture it while it is cheap to capture.
Is a full redesign realistically 6+ months out? If yes, "wait for the redesign" is not a plan, it is a decision to pay the 5x-10x rate on everything that sits idle in the meantime.
If you are weighing a full rebuild against fixing what exists, our decision framework for choosing between remediation and a rebuild walks through that specific fork in more depth. That framework and this article are complementary: this one explains why the clock matters at all, and that one helps you decide what to do once you have accepted that it does.
None of this requires guessing at your own numbers. Following an established framework like the W3C's core accessibility principles or a structured standard such as Section 508 gives you a concrete list of what "fixed" actually means, so the fix, whenever you make it, is measured against something real instead of a vague sense that things got "better."
The Cheapest Time to Fix It Is Always Right Now
The uncomfortable part of a defect cost curve is that it never offers a good moment to wait. Every stage you postpone to is more expensive than the one before it, which means the cheapest possible moment to fix a known issue is always the one you are standing in today. That is not a sales line, it is the same math that governs every other kind of software defect, applied to the ones assistive technology users run into first.
If you want a clear, current picture of where your own site sits on that curve before another quarter goes by, a good next step is a free accessibility audit. It gives you the specific list of what exists today, while today is still the cheap version of fixing it.
If you would rather talk it through with a person first, our team is reachable directly at experts@wcag.world, or you can start with the same free audit and bring the results to that conversation.