Security controls are often judged by the wrong moment. A team watches a staff member log in from a recent laptop, receive a one-time code, and reach the account. The control appears successful. The more demanding question is what happens when an authorised person uses a screen reader, cannot see a colour-only warning, has a slow connection, shares a phone, has limited dexterity, or has just lost the device that receives the code. In those circumstances a control can prevent an intruder while also preventing the person it was meant to protect from acting on their own behalf.
A secure route can still exclude its rightful user#
Consider a housing association that adds multi-factor authentication to its tenant portal. The intention is sound: repair requests, payment details, and personal documents should not be exposed. During an internal demonstration the second factor works perfectly. Yet a tenant using keyboard navigation finds that focus disappears after an error message; another cannot receive text messages in the underground workplace where they spend their day; a third has replaced a broken phone and discovers that every recovery option requires the old number. None of these people is attempting to bypass security. They are encountering a design that assumed one stable device and one convenient way of receiving information.
Consider a housing association that adds multi-factor authentication to its tenant portal.
The issue is not that every security step must be effortless. Some friction is purposeful. The issue is whether the friction has been tested against the lives of the people subject to it. A barrier may be proportionate for an attacker and disproportionate for a tenant trying to report a dangerous leak. If the only practical response is to borrow someone else's phone, disclose a code, or wait until an office opens, the system has created privacy and safety costs of its own. Those costs belong in the risk assessment.
Test a journey, not a component#
An accessibility test should ask people to complete a realistic task from beginning to end. Start with sign-in, but continue through receiving the challenge, correcting an error, using an alternative channel, and recovering access after a plausible incident. Observe whether each instruction can be perceived in more than one way, whether controls have clear names, whether time limits can be extended, and whether an error explains what to do next. A button that exists in the interface is not evidence that the route is usable.
The scenarios need variation. Invite people who use screen readers, zoom, voice control, switch access, or keyboard-only navigation. Include people with intermittent connectivity, older devices, shared accounts in the household, and limited confidence with digital processes. This is not a search for a token participant or a checklist of diagnoses. It is a way to uncover particular combinations of circumstances. A video-call-only recovery method may be simple for one person and impossible for another. A CAPTCHA may work on a large display but interrupt a user who navigates by audio. A sixty-second code may be reasonable on paper and punishing when a connection lags.
Record the obstacle precisely#
How a team describes a failed task determines whether it can improve the control. “The user could not finish authentication” says almost nothing. “The error was announced after the focus moved away; the text field had no accessible label; the resend option was only available after the timer expired” points to repairable conditions. The language should identify what the system did, not imply that the person lacked competence. People are often highly capable within the tools available to them; the design has simply failed to meet them there.
Success rate alone is also too thin a measure. Record the number of attempts, elapsed time, whether a person had to seek assistance, and whether they had to reveal a code or document to someone else. Those details show where a nominally secure process pushes people into weaker practices. A control that makes account recovery possible only through a family member may reduce one technical risk while creating another: loss of confidentiality, pressure to disclose information, or dependence on a relationship that is not safe. Security cannot be assessed only from the viewpoint of unauthorised access.
Recovery is where the promise is tested#
Account recovery is not an edge case. Phones fail, SIM cards change, inboxes are locked, and people travel or lose their belongings. A recovery design that requires the same device, number, and credentials that are no longer available has not planned for recovery; it has planned for uninterrupted luck. Testing should simulate a lost device, a changed number, and a temporary lockout. It should also test whether the person can get help without making a voice call, travelling in person, or sending more sensitive evidence than the decision requires.
Strong recovery uses layered options. A prepared backup code may be appropriate for some users. A hardware key can suit others. A verified contact channel, a cooling-off period with alerts, or a trained human review can offer further routes where risk justifies them. Human review is not automatically a loophole. It can be tightly documented, subject to clear authority, and checked for misuse. What matters is that it is discoverable, accessible, and governed rather than treated as an informal favour available only to people who know the right person.
Alternatives need controls as well as empathy#
It is reasonable to worry that a fallback route could be exploited. The answer is not to remove every fallback but to define its safeguards. For each option, ask what form of abuse it might enable, what evidence supports the decision, who may approve it, and what alert would reveal an unusual pattern. Then ask the complementary question: can an authorised person find the option, understand its requirements, and use it without surrendering unnecessary data or dignity? Both questions are necessary.
For instance, asking for a photographed identity document may be excessive for a low-risk change if an existing verified channel can confirm the request. Conversely, a high-risk change may justify a delay and notice to established contacts. Proportion matters. The least intrusive route that adequately manages the risk is usually more defensible than a single rigid method. It recognises that personal circumstances vary without pretending that every request should be accepted immediately.
Make findings operational#
After a test, turn observations into work that has an owner. Categorise each finding by consequence: complete lockout, meaningful delay, forced reliance on another person, confusing information likely to cause an unsafe action, or a smaller inconvenience. Assign a responsible role, a deadline, and a retest method. If a serious issue cannot be fixed immediately, publish a temporary, usable route rather than quietly accepting the exclusion. A known barrier is not less harmful because it has been written down internally.
The organisation should also explain the control in ordinary language. People need to know what it protects, what signals it uses, what happens when it fails, how long recovery takes, and how to request review. This is not a request to disclose defensive secrets. It is a way to let a person plan and act before an urgent situation turns into an improvised disclosure of personal data. Clear communication is part of operational safety.
A practical next test#
Choose one security measure already in use. Run three short scenarios: normal access using assistive technology, recovery after a lost device, and help-seeking on an unreliable connection. Do not coach participants through the task. Note the exact point where the route becomes unclear or impossible, the extra information the person is asked to provide, and the consequence of delay. Fix the most harmful obstacle, then repeat the same scenario.
Starting with potential harm changes the goal. The question is no longer merely whether a control is difficult to defeat. It is whether an authorised person can retain privacy, agency, and a realistic path to recovery when ordinary life disrupts the ideal flow. A security measure earns trust when its protections remain available to the people who need them most, not only to those whose circumstances perfectly match the original design.
