There is a famous play called "Waiting for Godot". It focuses on two friends sat on a bench waiting for someone called Godot. They believe this person will be their salvation, will sort out all their problems (you can see where I'm going with this). They wait, and wait, for days. Godot never appears, but they continue to wait, never moving forward.
The myth of the “future fix”
Quite often with legacy systems, there will be a redesign somewhere on the horizon. You know, the long-talked about redesign. The redesign that will solve everything. It's coming ("Godot will not be arriving tonight, but surely tomorrow"). This causes fixing accessibility issues on the project to grind to a halt. Why do it now when the redesign will fix everything? Why do the work twice? But these redesigns, they often get delayed, or even cancelled. And even if they do get delivered on time, what are users going to do in the meantime?
Legacy digital services are often framed as temporary problems. A redesign is coming. A replacement is planned. A transformation will fix everything. But for the people relying on these systems today, particularly for internal systems where using it is part of someone’s job, waiting is not harmless. It prolongs barriers, increases cognitive and physical effort, and quietly excludes users who rely on assistive technologies.
Accessibility in legacy systems is not about achieving perfection. It is about making meaningful improvement where it matters most. Are we going to fix everything? Probably not. But we can make it better today than it was yesterday and that makes a difference. Probably more than you could know.
Accepting constraints without lowering ambition
Legacy environments often come with real constraints. These can include undocumented interaction flows, a heavy dependence on domain knowledge, third‑party libraries with limited accessibility support, bespoke interaction models, and deeply embedded user behaviours built up over many years.
Accessibility work in this context must be pragmatic. That means aiming for what is achievable without destabilising the system, while still adhering to core accessibility principles. Progress is not blocked by constraints, but it is shaped by them.
Understanding the landscape first
Teams working on legacy services often know that accessibility issues exist but lack visibility of their scale or severity. Large audit reports can feel overwhelming and difficult to act on.
The first task is not fixing everything, but understanding the landscape. This means identifying what types of issues recur, which users are most affected, and where changes could unlock disproportionate benefit.
This is also where understanding how real-world users navigate the interface adds value. Observing them encounter barriers and then deploy their learned workarounds both feeds into options for remediation and provides valuable evidence for the reason for doing the work. It's much harder for a stakeholder say no to accessibility work after seeing a real user struggle with their system.
Why automation alone falls short
Automated testing plays a role, but its value drops sharply in heavily customised systems. These tools surface code‑level issues, not whether a real user can successfully complete a task using a screen reader, magnification, or speech recognition software.
Manual testing using assistive technologies reveals patterns that automation cannot. Fields without meaningful accessible names; purely visual relationships between content; keyboard focus being trapped, skipped, or moved unpredictably; interactions that fail entirely when users rely on speech input or keyboard‑only navigation. In legacy environments, accessibility must be tested where it fails in lived use.
Small fixes with meaningful impact
Some of the most effective accessibility improvements might require no visual redesign at all. Making sure inputs are correctly labelled, ensuring dynamic content updates are announced, and managing keyboard focus correctly, can all dramatically improve usability.
Individually, these changes may appear minor. Yet for people relying on assistive technologies, they can be transformational.
When pragmatism means presenting options
Not every issue can be solved incrementally. Some problems are structural and deeply embedded in the way a system was originally built.
In these cases, the goal shifts from immediate remediation to making options visible. This involves clarifying what can be improved with small changes, what would require deeper restructuring, and where additional testing or phased delivery would be required to manage risk. Accessibility work is as much about enabling informed decisions as it is about implementing fixes.
Turning findings into delivery
Accessibility audits only create value if they feed delivery in a practical way. Legacy systems can quickly spin up a large number of tickets, but just doing this is not going to yield useful results. Our output needs to be heavily categorised to allow the data to be sliced in multiple ways and decisions to be reached on best strategies for remediation. It also means prioritising based on user impact rather than technical severity alone, showing delivery teams how to fix common patterns once rather than repeating work, giving testers clear verification steps, and supporting realistic estimates and planning. Accessibility problems become solvable once they are structured.
Dropping hundreds of tickets into a backlog does not create progress (or any friends on the team!). Structured remediation does.
More than compliance
Improving accessibility in legacy systems often surfaces wider benefits - an accessibility audit is often the first time a comprehensive manual end-to-end review will have been carried out in a long time. It can expose long‑standing usability issues, hidden defects, undocumented workflows, performance bottlenecks, and opportunities for simplification. Accessibility becomes a lens through which the overall health of a system is revealed.
Conclusion
Legacy systems do not need to be written off to improve. They need pragmatism, prioritisation, incremental change, and a clear understanding of user impact. Accessibility work does not have to wait for the future to start making a difference. For users relying on these systems today, delayed improvement means prolonged exclusion.