Improve accessibility · Decisions and verification
Decide what to improve. Then check what changed.
A useful improvement is one that reduces a real barrier. A passing automated check, a completed ticket or a cleaner interface is not sufficient evidence by itself.
Prioritise using what you know
Consider these together rather than assigning a single score that hides uncertainty:
- Consequences: does this block an essential task, cause an error, or add avoidable effort?
- Who and how: which input methods, contexts and experiences have actually been considered? Avoid assuming a disability category from a barrier.
- Reach: does the problem occur across shared components, important journeys or multiple pages?
- Evidence: what was observed, reported or inferred? How confident are you, and what is missing?
- Practical dependencies: can a safe change be made now, or does it require deeper redesign?
High-impact barriers on essential journeys generally deserve prompt attention. Lack of precise prevalence data is not a reason to ignore a credible barrier.
Describe the intended improvement
Define the change in terms of the person's task. For example, “Someone can complete the selection without dragging” is more useful than “Make the UI accessible.” Check whether an alternative method genuinely achieves the same outcome.
Verify in the right context
- Repeat the original task using the original failing conditions, if known.
- Check the interaction with relevant keyboard, touch, voice, switch, screen-reader or other methods rather than presuming one represents all users.
- Look for regressions in focus, readability, errors, status changes and completion.
- Record what passed, what failed and what you did not test. Keep reports tied to exact environments.
- Where possible, involve people who encountered the barrier and listen to whether the improvement actually helps.
Testing guides and the Interface Lab can support this work, but controlled examples and automated checks do not replace evaluation of the real product.
Keep an inspectable improvement record
Task: What was someone trying to accomplish?
Evidence: What happened, and how do we know?
Change: What was modified and why?
Verification: What was re-tested, in which setup, and with what outcome?
Still unknown: What other input methods, environments or perspectives remain untested?
Follow-up: What needs review after release?
Accessibility doesn't end at release
Include accessibility in design decisions, content updates, procurement, acceptance criteria, regression testing and feedback handling. Make it possible for people to report barriers and receive a response from the responsible organisation.