Marta reached the date picker with one hand on the keyboard and the other on a notebook where she wrote down failing steps. She was booking an appointment at a municipal library; the form clearly said it could be completed without a mouse. When she opened the picker, focus vanished. She pressed Tab once, twice, ten times. The display changed month, yet she could not tell where she was or reach the confirm button. Escape closed a window without returning the cursor to the field that opened it. After several minutes, she abandoned the task and sent a short complaint: “With a keyboard, I get trapped.”
That sentence is small, but it contains an unfinished product decision. It can disappear into a suggestions inbox, become a loosely labelled technical ticket, or start a verifiable conversation. The difference is not whether a team says it listens. It is whether the team can describe the barrier, reproduce it, agree what must change to remove it, and return the result to the person who found it. Accessibility becomes shared accountability when a frustrating experience leaves evidence capable of changing the service.
A complaint is not a specification#
Marta did not say which code attribute to use or which component to replace. That was not her job. She asked to complete an action the service had invited her to perform. Translating her report as “keyboard broken” would not be enough: it does not identify where the journey breaks, what outcome the person expects, or how to verify that a fix does not introduce a new barrier.
Marta did not say which code attribute to use or which component to replace. That was not her job.
Before suggesting a change, the team recorded four facts. The goal was to select a date, confirm an appointment, and receive a receipt without a pointing device. The journey was booking link, service field, date picker, time slot, confirmation. The observation was that focus entered unannounced controls, did not return to the originating field when the window closed, and looped through Tab without a predictable exit. The impact was that the task became endless for a keyboard user, while the telephone alternative had different hours and no comparable immediacy.
This description avoids treating Marta as an exception who needs personal assistance. Someone may use a keyboard because of disability, temporary injury, fatigue, voice setup, or speed. A product does not need to know why in order to offer coherent interaction. It also avoids calling a phone number an equivalent alternative. An alternative is equivalent only when it allows the same action, with comparable information and timelines, without forcing someone to disclose a private difficulty.
Reproduction is not a test of the reporter#
The following morning, two designers and a developer reproduced the incident in a test environment. They started with a keyboard and the screen reader used in their routine checks. They found the focus loop quickly, then noticed something more troubling: the picker could close without returning position to the form. A person who sees the screen can recover the thread with a mouse; someone relying on focus order receives silence.
Reproduction turns an impression into evidence. It should not make the person who complained prove repeatedly that they deserve to be believed. The team therefore did not ask Marta for a video call or details about her circumstances. It told her which journey it was investigating and offered a later review only if she wished to take part. Consent to test must never be the price of taking an incident seriously.
The finding exposed an organisational gap too. The picker came from a component library maintained by another team. The visual review had checked contrast and type size, but nobody owned focus behaviour as an acceptance criterion. This was not merely a code defect; it was a missing definition of done. When no role must demonstrate that a journey can be started, travelled, and closed from a keyboard, the check depends on memory or goodwill.
Write a decision that can be checked#
The repair began with an outcome, not an impressive-looking solution. The ticket remained open with criteria that any colleague could review:
- When the picker opens, focus lands on an announced element explaining how to choose a date. - Every operable option is reachable by keyboard in an understandable order, with no exitless loop. - Escape closes the picker and returns focus to the field that opened it. - After a date is chosen, the value is communicated and the person can continue to confirmation. - The same journey is checked on desktop and on mobile with an external keyboard, without hidden instructions.
Those criteria make visible a decision that had previously been scattered across design, development, and quality assurance. They also distinguish repair from patching. Adding a help link beside the picker does not meet the goal if it makes a person leave the form. Moving focus automatically does not help if context disappears. The useful question is: can somebody complete the task while knowing where they are and what will happen next?
To avoid replacing one fragile response with another, the team considered adjusting the existing component, replacing it with a field that accepted typed dates, or delaying release until it could be tested. It combined the first two: stable keyboard navigation in the picker and a date field with an explained format. It was not presented as an “accessible mode,” because a secondary route can turn difference into stigma. It was the same function, made more dependable for everyone.
Test the repair outside the team’s bubble#
Automated checks now detected a focus cycle. That mattered, but it was not enough. A test can establish that focusable elements exist while missing that their order is meaningless when the calendar changes month. The team prepared three journeys: book the first available appointment, choose a specific date, and change service before confirmation. At each step they documented the expectation and logged both blocks and uncertainty.
Marta agreed to review the change from her own computer, without sharing her screen unless she chose to do so. She completed the first journey unaided. In the second, she pointed out that the month announcement came after the days, so she could choose a date without knowing which month it belonged to. That was not the original report, but it was a consequence the technical check had missed. The team corrected the order and tested again. Useful feedback is not a “yes, it works”; it is letting actual use challenge the assumptions in the repair.
Testing needs respectful limits. It cannot represent every person or replace continuing participation by diverse communities. Nor does it justify retaining recordings or profiles that are not needed to repair the issue. What it does is stop an organisation declaring victory simply because its staff know the product too well. A small, consented, well-documented piece of evidence can redirect a decision more effectively than a long requirements checklist marked from a distance.
Return the decision, not merely a closed ticket#
After deployment, the team did not send an automated thank-you. It wrote to Marta in plain language: it had identified a picker that trapped focus; it had changed navigation and added a clear date entry; it had checked the keyboard journey and found an additional improvement in the month announcement. It also explained what remained unfinished: other forms used the same component and would be reviewed over the next two weeks. It included a direct channel for reporting recurrence without requiring her to retell the entire story.
That response has practical value. It lets the reporter judge whether the organisation understood the harm, returns information that may prevent another failed attempt, and creates a commitment that can be checked. “We improved accessibility” cannot be tested. “Escape returns focus to the date field and Tab reaches confirm” can. Precision is not defensive technical language; it is respect.
The loop can be maintained with a small record for each incident: date, affected journey, observed barrier, acceptance criterion, owner, test performed, release decision, and return message. Reviewing those records monthly helps reveal components or practices that accumulate complaints. If three people become trapped in different menus, there may not be three isolated issues. There may be a design rule that needs to change.
When the next accessibility complaint arrives, the first response should not be a promise to forward it to the right department. It should name the journey and the missing exit. Then the team should agree how it will know the exit exists, test it without turning anyone into an object of examination, and explain what changed. Marta did not ask for a lesson in accessibility. She asked to book an appointment. Returning that ability, with an explanation she can verify, is the product decision that turns listening into accountability.
