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

This is where projects start to struggle. What looks like a small adjustment on the surface quickly exposes deeper issues. A contrast fix isn't just a colour change if the entire UI relies on colour to communicate meaning. Adding labels to a form isn't straightforward if the form was never structured properly to begin with. Making something keyboard accessible isn't a tweak if the assumes a mouse at every step. The further along the project is, the more expensive those problems become.

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

Why retrofitting works against the product

Because you're no longer working with . You're working against it. Retrofitting means trying to adapt a that wasn't designed to support it. You end up making compromises, layering fixes on top of existing patterns, and trying to minimise disruption rather than designing the right solution. It becomes about what's possible, not what's correct.

Late in a project, there's pressure to launch. Deadlines are set, budgets are tight, and there's little appetite for reworking core parts of the experience. becomes something to manage within those , rather than something that shapes them. That's when shortcuts happen. And those shortcuts rarely hold up.

Key takeaway

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

What changes when accessibility is built in from the start

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 doesn't rely on a single mode of use. You're not fixing problems. You're avoiding them.

Projects that in tend to move more smoothly. There's less rework, fewer late-stage surprises, and fewer compromises. Decisions are made with clearer , which leads to more consistent outcomes. Accessibility becomes part of the system, not something added to it.

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. doesn't fail at the audit stage. It fails at the point decisions are made without it.

Written by Andy Scott

Strategic design, UX and digital transformation thinking from real projects.

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