Accessibility

Retrofitting accessibility is where projects go wrong

Accessibility problems are usually created much earlier than the audit that exposes them. By the time they are being fixed, the hardest decisions have already been made.

Why late-stage accessibility work becomes expensive and fragile, and why projects move far more smoothly when inclusive design shapes the system from the start.

02 January 20246 min read

In short

Why late-stage accessibility work becomes expensive and fragile, and why projects move far more smoothly when inclusive design shapes the system from the start.

Why late discovery is where projects begin to struggle

The structure is locked in. The are defined. Components have been built, reused, and scaled. At that point, is no longer part of the design .

It becomes a problem to fix.

In my experience, this is where projects start to struggle.

By the time accessibility is being checked, most of the decisions that make it hard have already been made.

Why small fixes expose bigger structural problems

What looks like a small adjustment on the surface quickly exposes deeper issues. A contrast fix is not just a colour change if the entire UI relies on colour to communicate meaning. Adding labels to a form is not straightforward if the form was never structured properly to begin with. Making something keyboard accessible is not a tweak if the assumes a mouse at every step.

The further along the project is, the more expensive those problems become.

And the harder they are to solve properly.

Key takeaway

Late accessibility fixes rarely stay isolated. They reveal assumptions baked into structure, interaction, and component design.

Why retrofitting works against the product

Because you are no longer working with intent.

You are working against it.

Retrofitting means trying to adapt a that was not designed to support it. You end up making compromises, layering fixes on top of existing , and trying to minimise disruption rather than designing the right solution.

It becomes about what is possible, not what is correct.

Why the product can improve technically without getting better

This is where quietly degrades.

On paper, issues are resolved. Tickets are closed. Audits improve. But the underlying experience often remains fragile. Small inconsistencies creep in. are missed. behave differently depending on how they are accessed.

The product becomes technically improved, but not fundamentally better.

Why late-stage pressure creates the wrong decisions

What makes this more difficult is that the timing often works against you.

Late in a project, there is pressure to launch. Deadlines are set, budgets are tight, and there is little appetite for reworking core parts of the experience. becomes something to manage within those , rather than something that shapes them.

That is when shortcuts happen.

And those shortcuts rarely hold up.

What changes when accessibility is built in from the start

In contrast, when is considered from the beginning, it changes how everything is built. Content is structured properly from the start. Components are designed to work across different inputs. are thought through in a way that does not rely on a single mode of use.

You are not fixing problems.

You are avoiding them.

This is where the difference becomes clear.

Projects that in tend to move more smoothly. There is less rework, fewer late-stage surprises, and fewer compromises. Decisions are made with clearer , which leads to more consistent outcomes.

becomes part of the .

Not something added to it.

Why retrofitting is a false efficiency

The irony is that retrofitting often takes more time than doing it properly in the first place.

What seems like a quicker approach early on ends up creating more complexity later. Fixes take longer, decisions become harder, and the quality of the experience is still limited by what was originally built.

It is a false .

does not fail at the audit stage.

It fails at the point decisions are made without it.

And by the time you are trying to retrofit it, you are already working from the back foot.

LET'S WORK TOGETHER

Ready to improve your product?

UX, research and product leadership for teams tackling complex digital services. The work usually starts where things have become harder than they need to be: unclear journeys, inconsistent products, competing priorities, or teams trying to move forward without a clear direction. I help simplify the problem, shape the right next step, and turn complexity into something people can actually use.

Previous feedback

Will Parkhouse

Senior Content Designer

01/20