A screen can pass a technical review and still leave someone stranded at the moment they need to do something important. That is why “does it look accessible?” is the wrong starting question. A better question is whether different people can complete a need without guessing hidden rules, disclosing more information than necessary, or relying on a favour. Consider someone changing the delivery address for a medicine. This is not an abstract exercise: a mistake can affect treatment. In that situation, inclusion becomes visible in the choices the service makes understandable, the time it allows, and the way it lets a person recover from an error.
The first sign is understanding the assignment#
Before checking contrast or screen-reader behaviour, check whether the service explains the task. In an address-change journey, a person should know which details are required, why they are requested, and what will happen when they finish. A sequence of marked fields and buttons hands all interpretation to the user. Someone may submit the form without knowing whether the change is immediate, needs later confirmation, or will apply to the next delivery. That uncertainty is a barrier even when no technical error appears.
Before checking contrast or screen-reader behaviour, check whether the service explains the task.
During a test, ask the person to describe the journey in their own words before they confirm it. If they can predict the next step and recognise the intended outcome, that is meaningful evidence. If they need to return repeatedly, ask what a label means, or try several options, keep that specific observation. Saying that an experience was poor is vague; knowing that one sentence caused doubt gives a team a decision it can repair.
Clear guidance must survive different speeds#
An instruction is not clear merely because it fits on one line. Some people read slowly, enlarge text, move between an email and a web page, or need to pause to check a detail. An inclusive interface preserves context when pace changes. It does not hide the key notice after a few seconds; it keeps a short reference near the action. It does not erase every completed field when one item needs correction; it identifies what is missing and respects the work already done.
Try the task with browser zoom enlarged and a narrow window. Then interrupt it and return after a few minutes. Is it still obvious what the person was doing? Are the messages still available? These questions matter especially in health, education, housing, and support services, where fatigue, a phone call, or unstable connectivity can interrupt a journey. Progress is visible when a system accommodates ordinary life, not only a flawless uninterrupted demonstration.
An alternative must reach the same outcome#
“Contact us if you have difficulty” may be useful support, but it is not automatically an alternative route. The fair comparison is simple: can the person obtain the same change, the same record, and a similar timeframe without disproportionate effort? If the digital route confirms an address instantly while the phone route requires repeated calls during working hours, the routes are not equivalent. If the alternative requires someone to explain a health condition to obtain routine help, it adds a privacy barrier.
Test the alternative end to end. Make the enquiry, ask for the transaction, and confirm that the response provides the same final information. If in-person help exists, check how someone reaches it and whether an appointment can only be obtained through an inaccessible channel. Record time, requested documents, and outcome, not merely a phone number or a help link. This prevents a promise of support from quietly relocating the problem to the person who needs the service.
Recovery tells more than the ideal route#
Teams often test the intended path: enter the expected details, select continue, and read a confirmation. Many barriers emerge when something goes wrong. A person may mistype one digit of a postcode, choose a similarly named street, or lose connectivity before saving. Accessible technology identifies the problem without blame, explains how to resolve it, and keeps the work that was already correct.
Look closely at the message quality. “Invalid format” offers no route forward; “enter the five postcode digits without spaces” supports a specific action. The notice should work without colour alone, be reachable by keyboard, and be announced to people using screen-reading support. It should also appear near the decision that needs attention, rather than at the top of a long page. When several people fail at the same point, treat the pattern as evidence of a design that needs review, not as a personal deficiency.
Autonomy also protects personal information#
Accessibility and privacy meet in small details. Someone who needs time to understand a field should not have to expose their address, case number, or health information to the person beside them. Inclusive design reduces that exposure through comprehensible labels, a review step before submission, explanations of each data use, and a visible way to leave without losing all control of the form.
Use fictional data in testing whenever possible. Keep only the minimum evidence needed to reproduce a fault; do not accumulate screenshots containing full records or continuous recordings. Ask permission before observing a person navigate, and make clear that the session can stop. These safeguards do not slow improvement. They make participation safer and the resulting evidence more trustworthy.
Technical requirements matter inside a task#
Visible focus, logical control order, sufficient contrast, and resizable text are testable conditions. Their value appears when they protect a real action. In the address-change task, attempt every field without a mouse. Check that focus does not disappear when a street selector opens and that it returns to a sensible place when a dialog closes. Enlarge text until it can be read without pushing the final button out of view.
Also test on a slow connection. Notices that vanish quickly can exclude someone who reads with assistance or has an unstable network. A good sign is that the application explains it is processing, prevents duplicate submissions, and offers a confirmation that can be retrieved later. Nobody needs to understand every underlying mechanism; the point is to check that those mechanisms preserve the person’s intention to finish the task.
Listening is discovery, not a request for approval#
Inviting users into testing is not a way to collect reassuring comments. It is a way to discover decisions a familiar team can no longer see. Prepare a short session, a plausible situation, and permission to stop. Rather than asking whether people liked it, ask what they expected to happen or what they would do without another person present. Their answers reveal missing information without making them responsible for the barrier.
Then return what you learned. If a suggestion will not be adopted, explain why and what alternative will be tested. If it will be adopted, say when it will be available and how it will be checked. This response makes participation respectful rather than extractive. It also creates a useful record for the next update, when a seemingly small change could break a journey that previously worked.
When an issue needs specialist support#
Not every problem needs the same response. A confusing label may improve through a content review and a fresh test. Seek specialist support when a barrier affects rights, safety, an automated decision that no one can explain, or an essential service. Escalation is also sensible when a team does not know how to test with assistive technology, affected people receive contradictory answers, or a proposed fix requires sensitive disclosure.
Support may come from an accessibility specialist, a professional responsible for the service, a data-protection lead, or an organisation familiar with the experiences of affected users. Bring evidence: the precise step, the access method, the expected result, the actual result, and the consequence. You do not need to diagnose the cause before asking for help. You need to describe the risk accurately and prevent the issue from being dismissed as an isolated opinion.
A small record for choosing priorities#
A giant dashboard is unnecessary to see whether a correction works. For each important task, record completions, abandonment, support requests, repeated errors, and time added by a barrier. Keep measurement separate from interpretation: a long time might indicate careful reading, or it might expose ambiguous guidance. Add short observations from testing and state what could not be measured.
Review the record after an improvement. If abandonment falls while support calls rise, the problem may have moved rather than disappeared. If keyboard access works but a screen reader does not announce an error, the improvement is partial. Naming limits prevents inflated promises and lets the next cycle begin exactly where work remains.
Close with an action that can be checked#
It is not enough to promise continuous improvement. Choose one real transaction, assign an owner, and set a date to repeat it under a different condition: without a mouse, with enlarged text, from an older phone, or after an interruption. Share internally what changed, what evidence supports it, and which limit remains open. That makes accessibility a maintained practice rather than a memory from a meeting.
Next week, test one complete transaction—such as changing an address—until it produces a retrievable confirmation. Do it with a keyboard, on a slow connection, and with someone unfamiliar with the service. If any of those tests requires guessing, unexplained waiting, or unnecessary disclosure, you have a clear signal. There is no need to find someone to blame: repair that step and test the outcome again.
