Information checked: 21 July 2026.
Accessibility improvement works best as a prioritised programme. Fix barriers that stop people completing essential tasks before polishing minor technical warnings across low-value pages.
In brief: Fix the highest-impact customer barriers, then prevent recurrence through shared components and release checks.
Prioritise by user impact
| Priority | Example | Response |
|---|---|---|
| Critical | Cannot submit, pay, book or contact without a mouse | Provide immediate alternative and fix urgently |
| High | Error is not announced or content cannot be read at zoom | Schedule in the current release cycle |
| Medium | Navigation is confusing but task remains possible | Plan and test a design improvement |
| Low | Minor semantic or consistency issue | Add to backlog and prevent recurrence |
Fix patterns, not isolated pages
- Correct shared templates and components first.
- Update the design system with accessible states.
- Improve CMS author guidance for headings, links, tables and images.
- Replace inaccessible third-party widgets where the supplier cannot remediate them.
- Add automated and manual checks to release acceptance.
Measure the outcome
Retest the original task with the same method and record whether the barrier is removed. A code change that satisfies a rule but leaves the task confusing is not a complete improvement.
Maintain transparency
Where a barrier cannot be fixed immediately, document it accurately, provide an accessible alternative and set an owner and target date. Do not promise a feature or format that staff cannot deliver.
Acceptance check
The improvement programme should show fewer blocked customer journeys, recurring defects prevented in shared components and a working route for user feedback.
Avoid endless low-impact remediation
A backlog can become dominated by easy colour or markup fixes while a booking journey remains unusable. Rank by whether the issue blocks, delays or confuses a real task, then address shared root causes before individual symptoms.
Records to keep
- Impact-based priority and affected journey.
- Shared component or content-source diagnosis.
- Owner, target release and alternative route.
- Evidence that the original user barrier was removed.
Owner test: Review the top ten items and confirm that their order reflects customer impact rather than developer convenience.
Sources and date checked
This practical guidance was checked against the following primary sources. Legal duties depend on the organisation and service, so obtain qualified advice where the consequences are significant. Date checked: 21 July 2026.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.