Menu

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 20244 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

The projects that struggle 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 journeys are defined, and the components are built around assumptions that don't account for how different people actually use the product. At that point, you're no longer designing for accessibility. You're trying to patch around decisions that were never designed to support it.

The word is doing quiet damage here. Features are scoped, prioritised, and traded against each other, which means enters the as something that can be deferred to the next release. Constraints do not work that way, and framing it as one changes which conversations are even possible.

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

Simple changes stop being simple. Adjusting a colour palette might seem straightforward, but if the design relies heavily on colour to communicate meaning, that change ripples through the entire experience. Forms designed visually need reworking 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's rarely done properly.

concentrate the cost. One inaccessible component used in forty places is not forty small fixes, it is a change to a shared , a regression risk across every consumer of it, and a coordination problem across whichever teams own those screens.

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

isn't just about whether something technically passes a guideline. It's about whether someone can actually use it. There's a significant gap between something being compliant and something being usable, and that gap is where most accessible products fall down. I've 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.

The gap is widest on anything the guidelines cannot express as a rule. Whether an error message tells you what to do next, whether a heading structure describes the content or just controls type size, whether alternative text says what an image is doing there. All of these can pass and still be useless.

Which is why a pass is best treated as the start of the assessment rather than the end of it. It establishes there are no technical barriers. It says nothing about whether the journey is reasonable to complete.

Why accessibility is a design constraint

isn't a you add. It's a constraint you design within. When is treated as a requirement from the start, decisions are made differently. Content is structured more clearly. Interactions are designed to work across different input methods. Complexity is reduced, not just for accessibility, but because the experience has to make sense in multiple contexts. It forces better thinking.

applied early tend to improve work rather than restrict it. Being unable to rely on colour alone forces a second signal that helps everyone. Having to make sense read aloud in order forces a structure that scans better visually as well.

Why designing accessibly improves the whole product

Designing for a wider range of users naturally to simpler, clearer, more robust experiences. When you can't rely on visual cues alone, you're 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 isn't just more inclusive. It's better.

Teams who take seriously early on move faster later. There's less rework, fewer blockers, and fewer surprises during testing. becomes part of how the product is built, not something that needs to be fixed. The alternative is always more expensive, not just in time and budget, but in missed users, lost , and in some cases, legal exposure.

There is a commercial of this argument that lands more easily with people who are not persuaded by the principle. Around one in five people in the UK has a disability, procurement increasingly ask for conformance evidence, and the situational cases are larger still. It is a wide audience being excluded by decisions nobody deliberately made.

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