Accessibility

Accessibility is not a feature, it is a requirement

Accessibility only works when it shapes decisions from the start. Treated as a final-layer fix, it becomes expensive, incomplete, and too easy to get wrong.

Why retrofitting accessibility creates more problems than it solves, and why the strongest digital products treat it as a core requirement rather than a launch checklist item.

14 March 20246 min read

In short

Why retrofitting accessibility creates more problems than it solves, and why the strongest digital products treat it as a core requirement rather than a launch checklist item.

Why accessibility breaks when it is treated as a layer

On paper, that looks like progress.

In reality, it is usually where the problem starts.

Because does not work as a layer.

In my experience, the projects that struggle the most with are not the ones that ignore it completely, but the ones that try to retrofit it. By the time is considered, key decisions have already been made. The structure is set, the are defined, and the components are built around assumptions that do not account for how different people actually use the product.

At that point, you are no longer designing for .

You are trying to patch around decisions that were never designed to support it.

Accessibility becomes expensive the moment it is treated as something to add after the experience has already been defined.

Why retrofit work gets expensive fast

This is where the cost begins to show.

Simple changes are no longer simple. Adjusting a colour palette might seem straightforward, but if the design relies heavily on colour to communicate meaning, that change starts to ripple through the entire experience. Forms that were designed visually need to be reworked to function properly with . that makes sense on screen becomes confusing when read out of .

What should have been foundational becomes expensive to fix.

And even then, it is rarely done properly.

Key takeaway

Once structure, journeys, and components are built without accessibility in mind, even small fixes start creating wider redesign work.

Why compliance alone is not enough

Because is not just about whether something technically passes a guideline. It is about whether someone can actually use it.

There is a big difference between something being compliant and something being usable, and that gap is where most accessible products fall down.

I have seen that technically meet standards, but still leave users struggling to complete basic tasks. Not because the rules were ignored, but because the experience itself was not designed with those users in mind.

That is the shift that needs to happen.

Why accessibility is a design constraint

is not a you add.

It is a constraint you design within.

When is treated as a requirement from the start, the approach changes completely. Decisions are made differently. Content is structured more clearly. are designed to work across different input methods, not just the most common ones. Complexity is reduced, not just for , but because the experience has to make sense in multiple contexts.

It forces better thinking.

Why designing accessibly improves the whole product

This is where stops being a limitation and starts becoming an advantage.

Designing for a wider range of users naturally to simpler, clearer, more robust experiences. When you cannot rely on visual cues alone, you are forced to communicate more effectively. When need to work without precision input, you remove unnecessary . When content needs to be understood quickly, you reduce noise.

The result is not just more inclusive.

It is better.

Why some sectors cannot afford to treat it as optional

In sectors like healthcare and finance, this is not optional.

is tied directly to compliance, legal risk, and public . If someone cannot access a because of how it has been designed, that is not just a usability issue, it is a failure to deliver the service at all. Regulations like WCAG and GDS standards exist for a reason, but treating them as a box-ticking exercise misses the point.

The goal is not to pass.

It is to work.

And that only happens when is built in from the beginning.

Why early accessibility creates better momentum later

What I have found over time is that teams who take seriously early on move faster later. There is less rework, fewer blockers, and fewer surprises during testing. Decisions are clearer because they are grounded in real , not ideal scenarios.

It becomes part of how the product is built, not something that needs to be fixed.

The alternative is always more expensive.

Not just in terms of time and budget, but in missed users, lost , and in some cases, legal exposure. issues rarely stay hidden. They surface through complaints, failed audits, or worse, through users who simply cannot use what has been built.

By then, it is already too late to treat as optional.

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