The Fix Is Cheapest While You're Still Looking At It

Ask most teams when accessibility gets checked, and the answer is often “the audit.” Somewhere near the end of a project, before launch, a report comes back with a list of things to fix. That’s not wrong, it’s just late.

By the time an issue shows up in an audit, the component that has it was built weeks earlier, by someone who’s already moved on to the next thing. The audit didn’t prevent the problem. It found what had already shipped, because nothing earlier in the process was set up to catch it.

I spent years leading UX engineering teams and collaborating closely with designers, and the pattern was consistent across nearly every project: the cost of an accessibility fix wasn’t set by how hard the fix was. It was set by how long the fix had been sitting there before anyone noticed it.

A component fixed once is fixed everywhere it’s used

Most interfaces are built from a small set of reusable pieces — buttons, form fields, navigation patterns, cards — assembled into pages rather than built one page at a time. That’s good practice for many reasons, and it’s also exactly why an accessibility defect in a shared component is so expensive to leave in place.

A missing focus state or an unlabeled icon button isn’t a one-page problem. It’s a one-component problem that gets multiplied by every page that component appears on. Catch it while the component is being built, and it’s a single fix in a single file. Catch it during an audit six weeks later, after the component has shipped across twenty pages, and it’s the same defect — just multiplied by every place it was reused in the meantime.

The context is gone by the time the audit finds it

The other cost isn’t the fix itself. It’s reconstructing context that’s already gone. The developer who built the component has moved on to other work. The sprint it shipped in is closed. Nobody flagged the issue at the time because nobody was looking for it — accessibility wasn’t part of how the component got reviewed, so it just is what it is now, a defect in production that someone else has to untangle from scratch.

Compare that to catching the same issue while the person who built it is still looking at the code. The context hasn’t gone anywhere. The fix is usually small, because the component hasn’t been reused anywhere yet — there’s nothing built on top of it to unwind.

This is where tooling matters more than most teams expect. There are accessibility testing plugins that run inside the same development environment a team is already using — flagging issues in real time, on the component a developer is actively working on, rather than in a separate report weeks later. The best version of this isn’t a smarter audit. It’s making the feedback loop the same length as the one developers already use for everything else they build: write it, see if it works, fix it, move on. Teams that adopt tooling like this don’t just ship fewer defects — the developers using it get faster at spotting the pattern themselves over time, and start catching issues before the tool even flags them.

Audits still matter — they’re just not where the real leverage is

None of this leaves audits without a job. A good audit still catches issues that only surface once everything is assembled — a focus order that breaks across a page transition, an interaction between two components that each tested fine on their own, a flow that only reveals a problem when a real user moves through the whole thing end to end. That’s a different kind of check than testing a single component in isolation, and it’s still worth doing.

But a lot of what an audit would otherwise flag never gets that far in the first place, because an accessibility-aware designer specified focus order, states, and interaction behavior up front, in close collaboration with the developers building it. That’s prevention happening earlier still — before the component exists to test at all.

An audit is a backstop, not a prevention strategy. Treating it as the primary place accessibility gets caught means treating every defect as if it’s still cheap to fix — right up until the audit reveals how many pages it actually touched.

The pattern holds regardless of team size

None of this requires a large team or an unusual level of process maturity. It requires treating accessibility as part of how components get built, not a category of bug found after they ship. The fix is the same fix either way. The only thing that changes is how much it costs to make it, and how much of the codebase it’s had time to spread across before anyone looks.

Which is really the point. The fix is cheapest while the person who built it is still looking at it — and every week that passes after that is a week the same defect has to be found and unwound somewhere new.