Menu

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 20243 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.

The cost curve is not linear either. An issue caught in a wireframe costs a conversation. The same issue caught in a component costs a change to every screen using it. Caught after launch, it costs that rebuild plus a remediation plan, a retest, and whatever the delay does to everything queued behind it.

It also tends to surface in the worst possible way: through an external audit, a complaint, or a procurement questionnaire nobody saw coming. By that point has stopped being a design consideration and become a compliance problem with a deadline attached, which is the least useful frame for actually solving it.

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.

There is a second cost that rarely gets counted. Every workaround added at this stage becomes something the team has to maintain and explain. The component now has an exception. The now has a nobody documented. Six months later the reasoning has gone, and the next person around the exception rather than through it.

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.

None of this requires an specialist attached to every ticket. It requires three questions asked early enough to matter: can this be operated without a mouse, does this still make sense read aloud in order, and does anything here rely on colour alone to carry meaning. Asked in a design review, they take minutes. Asked after launch, they take a project.

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.

Previous feedback

I had a fantastic experience working with Andy. One of his most impressive achievements during our time at NHS HEE was masterminding a deeply complex information architecture for a new platform that brought together a large number of legacy websites.

Will Parkhouse

Senior Content Designer