Legacy-system accessibility begins with the work people need to do. An old interface may sit in front of valuable records and business rules, while a new interface may still depend on those same systems. Compare options by the access they deliver, the functions they preserve and the maintenance they require. A small proof of concept can reveal whether a proposed route actually supports an essential task.
Separate the interface from the underlying work
List users, roles, essential operations, data inputs and outputs, integrations and support contacts. Identify where each barrier occurs: navigation, a control, a timed interaction, a generated document or a downstream system. Record operating-system and assistive-technology dependencies where they affect testing.
Ask what can be changed. Do you control the source? Is the vendor still supporting the deployed version? Is there a documented interface for exchanging data? Which business rules must be preserved? Get answers from the system owner and relevant specialists before choosing a modernization strategy.
Compare three practical routes
| Route | When to investigate | Evidence needed |
|---|---|---|
| Repair the existing interface | Source or supported configuration can be changed | A representative task works after repair in supported environments |
| Add an accessible front end | A maintained integration can expose the required functions | Complete workflows, errors and outputs work through the new route |
| Replace the system | Support, architecture or repeated limitations obstruct sustainable repair | Migration preserves needed records, functions and usable access |
Each option has dependencies. A front end can inherit inaccessible documents or omit a rare but essential function. Replacement can introduce new barriers while data and processes are being moved. Evaluate the result people receive, including support and recovery paths.
Test a representative slice before committing
- Choose an important task with a normal path and at least one realistic error or exception.
- Build or configure the smallest prototype that exercises the proposed route using approved test data.
- Have the appropriate specialists verify data handling, permissions, business rules and accessibility.
- Test with the access tools and user roles required in the intended environment.
- Record what is demonstrated, what remains simulated and what would still need production work.
W3C’s conformance-evaluation overview helps frame scope and sampling for web content. Desktop and other ICT components need requirements and evaluation suited to their technology. Establish applicable Section 508 requirements separately with the responsible team.
Make the tradeoff explicit
Compare implementation effort, licensing and support, integration ownership, regression testing, staff training and eventual retirement. Use dated estimates supplied for the actual system; a generic promise of quick compliance cannot settle the decision.
Keep an interim access arrangement while the permanent route is being tested, with a responsible owner and a review date. W3C’s interim-repair guidance is useful for distinguishing immediate help from the broader repair program.
Maintain the route after migration
Document the chosen architecture, supported configurations and essential journeys. Assign ownership of integration changes, generated content and user feedback. Retest after a back-end update as well as an interface update; a changed field, permission or error response can alter the experience.
Retain evidence of what was actually evaluated and any excluded functions. Involve proficient assistive-technology users and evaluation specialists; a quick simulation by someone unfamiliar with a screen reader gives limited information about real use. The integration guide provides a way to extend this work across the complete service.