Retrofitting costs far more than building accessibility in

What it is

If the component library ships names, focus, and keyboard behaviour on day one, every later screen reuses them. If custom widgets are bolted onto the accessibility tree after launch, the work faces forked implementations, broken tests, and forgotten product decisions. Accessibility retrofit cost compares the same capability at two moments: at design time it is a constraint; after launch it is rework — regression, retraining, coordination, and users already lost, not merely a few extra attributes.

Why it happens

Design time puts the constraint in a shared layer, so the marginal cost is close to “another state.” After launch every screen is a special case: a custom listbox, a hit target inside a canvas, focus trapped in an animation, each reverse-engineered on its own. The second layer is that the expensive part is rarely a line of alternative text. It is dragging an interaction model back from “only a pointer makes sense” — rewriting state machines, reteaching the team, and retesting every feature written against the old model. Time inflates the bill: people leave, documents vanish, a vendor contract freezes a widget version.

Studying it

Book effort by the phase a defect came from: hours to fix a capability in a shared component at design time, versus hours to fix the same class of issue on n live screens plus regression. Separate “copy change” bills from “interaction-model change” bills. Do not invent cross-industry multipliers; compare two timelines on this product.

Independent variables: when the capability entered the shared component (design time / post-launch). Dependent variables: person-hours, regression rounds, screens touched, releases slipped because of the retrofit.

Construction retrofit invoices do not transfer onto software — there is no ramp geometry, but there is component fan-out and state-machine rework. Report them apart.

Where it stops holding

Surface items such as contrast, alternative text, and caption tracks are relatively cheap to add later. They neither falsify the cost gap nor stand in for the whole retrofit. On a ten-year legacy system, “design time” has already passed; the comparison is “include it in the next rewrite” versus “wait another year,” not a return to kickoff. Some retrofits are triggered suddenly by regulation or litigation, and the budget shape differs from a voluntary refactor. Internal tools with few users may look cheap in absolute terms; cost per user still tracks “later is dearer.”

Applying it

• A new component that does not provide name, role, focus, and keyboard behaviour does not land in the shared library.
• When estimating a retrofit, put regression and screen count on the invoice; do not estimate only “hours to add ARIA.”
• Force accessibility onto planned rewrite windows (design-system upgrades, checkout rebuilds) rather than waiting for a standalone budget line.
• How to check: pick one live custom widget, multiply the screens it appears on by the hours to complete keyboard and name support, and compare that with the hours to have made it a library component. Put the gap into the next design review as the grounds for “now or later.”

Related

• Same group: J1.09.2 Structural problems cannot be patched later · J1.09.3 Accessibility belongs in requirements, not in the acceptance checklist
• Nearby: Z8.06 Accessibility requirements for public facilities · J5.14 Testing with Disabled Users
• Search terms: accessibility retrofit cost · shift-left accessibility · component-level inclusion