On Tuesday morning, Lucía opened the new screen for changing her municipal address on her phone. The journey looked short: five fields and one blue button. When she enlarged the text, though, the button moved out of view and the invalid-data message appeared for one second. Lucía did not say the application was “bad”; she closed the tab and asked her sister to complete the task from a computer. That scene is neither proof of an individual failure nor evidence that the entire service is worthless. It is a specific clue. The team needs to observe what happened when text enlarged, which information disappeared, and what genuine alternative was available before declaring the change complete.
Reviewing accessibility without blame does not mean softening a problem or postponing repair. It means separating an observed fact from a label. “Three people did not find the error message at 200 percent text size” is a fact that supports action. “People do not know how to use phones” transfers responsibility and ends the investigation. The distinction matters because digital products change through small decisions: a designer chose where a notice lives, a developer defined focus behaviour, a content editor shortened an instruction, and a manager approved a date. When the conversation begins with accusation, each person protects their territory. When it begins by describing a barrier and its consequence, the group can repair the system.
Making the context clear#
A useful review starts with a task that has consequences for the person doing it. Walking through a homepage or celebrating fast loading is not enough. Choose a complete action: apply for a grant, download a bill, confirm a medical appointment, or recover a password. Record who is attempting it, what outcome they expect, and what they must retain at the end: a receipt, confidence that a request arrived, a document copy, or a route for correction. The useful question is not “does this screen comply?” but “can this person achieve the purpose without relying on help that was never promised?” This anchors review in autonomy rather than in an abstract checklist.
A useful review starts with a task that has consequences for the person doing it.
A municipal form shows why context must be examined. A team had added visible labels, adequate contrast, and required fields. During testing, a person navigating by keyboard entered an incorrect date. The warning appeared at the bottom of the page, but focus stayed in the first field and the screen reader did not announce the issue. Technically, a message existed; in the actual experience, the task felt stalled without explanation. Repair did not require blaming the developer or the user. It required describing the interaction order, moving focus predictably, announcing an error summary, and testing the same task again. The second test could close only when the person found, understood, and corrected the date independently.
What changes in practice#
Inclusion is also tested in what happens when the primary route fails. Many organisations announce “you can call us” as an alternative without knowing whether calls are answered, whether the line supports relay services, whether callers must repeat sensitive data, or whether the hours exclude working people. An alternative is not a reassuring label. It must reach the same result with a comparable burden. At a housing cooperative, the incident portal used a draggable map that could not be operated with a keyboard. The team proposed email, but email required describing a location without meaningful reference points. The useful repair was an address field with suggestions, keyboard controls, and text confirmation, plus an assisted channel recording the same request. Testing both routes prevented the “alternative” from becoming another barrier.
Metrics help when they support questions rather than justify a quick success. Counts of completions, abandonment, repeated steps, and support requests can reveal patterns that an internal demonstration hides. Yet a number never tells the entire story. Increased time on a task may signal confusion, or it may show that instructions are now understandable and people are checking their information more carefully. Each record should therefore include the task, device, interaction method chosen, and a brief account of what happened, without collecting unnecessary diagnoses. Comparing before and after a repair, while naming what was not measured, creates an honest review. The aim is not a green dashboard. It is to learn whether the next decision removes an avoidable dependency.
Deciding with information#
Listening does not mean asking a disabled person to validate a solution that has already been chosen, for free. It means creating conditions in which they can name friction without defending their experience. Before a session, explain what will be observed, what data will be retained, who will read the notes, and how they will be removed. During the task, “what did you expect to happen?” is more useful than “why did you not press there?” Afterwards, the team must respond: what it will change, what it cannot yet change, and when it will check again. In a library, this practice revealed that automatic captions in the audiovisual catalogue confused proper names. Correcting them was not cosmetic. It enabled people to find activities and materials without asking somebody else to interpret the video.
Privacy is part of accessibility because help requiring more disclosure than necessary is not safe help. During a review of digital identification, a team considered recording every screen in order to “analyse blocks better.” Test accounts, an observation template, and consent for minimal notes were enough. Account recovery needed review too: requiring a photograph of an identity document and sending it by email could exclude people without a camera, with limited connectivity, or with justified reluctance to share it. The responsible question has two parts: what evidence is necessary to repair the barrier, and what evidence would be invasive without adding value? Designing that boundary protects the person testing and improves the quality of later decisions.
Reviewing and adjusting#
Sometimes a team must pause and seek specialist knowledge. This is true when a barrier affects a right, health care, an automated decision, or an essential service; it is also true when an interaction with assistive technology is not understood. Seeking support does not erase internal responsibility. The organisation must retain the case, explain the impact, implement the repair, and verify it afterwards. W3C's WCAG, European requirements, and data-protection guidance provide valuable criteria, but they do not replace a person attempting a real task. A criterion explains what to inspect. Situated testing shows whether the outcome makes sense in daily use.
These ideas can become routine through a short, disciplined meeting. Once per cycle, a team can choose one task, reproduce an observed incident, name the person responsible for fixing it, and set a date to repeat the test. The note should preserve learning rather than blame: “the warning disappeared before it could be read; we will retain the message and announce the summary”; “the help link opened another page without context; we will add an explanation before it opens.” When a repair cannot fit the current cycle, record its risk and communicate a safe route until it arrives. Accessibility debt does not become acceptable by calling it temporary, but it is managed more honestly when nobody needs to hide it.
Lucía's verifiable progress would not be a public statement about inclusion. It would be her ability, using enlarged text on the device she actually uses, to see the error at the right moment, understand how to correct it, retain her data, and receive a clear confirmation. To review your next change, select one essential task today and one use condition different from the usual one: keyboard-only navigation, enlarged text, a slow connection, captions, or assisted reading. Observe the journey without offering excuses in advance. Record the barrier, repair one concrete cause, and repeat the same test with someone who did not design the screen. That small practice makes accessibility shared quality work, not a promise reviewed only after something goes wrong.
