Traditional password and one-time passcode flows create accessibility risk because they ask users to remember or re-enter information as part of authentication. WCAG 2.2 treats those steps as cognitive function tests, which can exclude people with disabilities, language barriers, or age-related limitations. Organisations that keep these methods need a non-cognitive alternative to remain accessible.
Why password and one-time passcode flows become an accessibility problem
Password and OTP-based authentication can exclude users when the flow depends on memory, transcription, rapid re-entry, or switching context between devices. That matters because accessibility failures are not limited to total inability to sign in, they also include burdens that are unnecessarily hard for users with cognitive, motor, sensory, language, or age-related limitations.
The practical issue is not that every password or passcode is always unusable, but that these controls often rely on a user performing a recall task at the exact moment access is needed. If the authentication step itself becomes the barrier, the organisation has made access contingent on a cognitive performance test rather than a usable login path.
How WCAG 2.2 treats authentication steps that depend on recall
WCAG 2.2 pushes organisations to design authentication so users are not forced to remember or re-enter information if a non-cognitive alternative is available. That is especially important for flows that require entering a password and then handling a one-time code, because the combined process adds friction, time pressure, and error risk even when each step seems routine to designers.
This is why accessibility review should focus on the actual login journey, not only the presence of a second factor. A technically stronger authentication flow can still be inaccessible if it excludes users who cannot reliably complete memory-heavy or multi-step challenges without assistance.
Where organisations do keep passwords or passcodes, the design question becomes whether there is an equivalent path that does not depend on recall at all. Good accessibility practice is to make the alternative path real, supported, and available in the same operational context as the default path.
What organisations should change to reduce accessibility friction
Teams should evaluate sign-in from the user’s point of view: can the person complete the flow independently, on the first attempt, and without needing to memorise transient values or move between devices under time pressure? If not, the authentication design needs adjustment rather than just more user instructions.
A useful benchmark is whether the login method offers a non-cognitive option such as a passkey, device-bound authentication, or another accessible method that reduces recall and transcription burden. For guidance on stronger authentication patterns, compare the flow with NIST SP 800-63 Digital Identity Guidelines, which emphasise phishing-resistant and user-friendly authenticator choices.
Accessibility teams and security teams should also coordinate on exception handling. If a user cannot complete a standard password or OTP journey, the recovery path must be accessible too, otherwise the organisation has only moved the barrier from sign-in to account recovery.
Risk and Threat Considerations
Password and OTP flows create avoidable exclusion risk when they rely on memory, fast transcription, or second-device interaction. The problem is amplified in high-friction environments such as mobile, call-centre, shared-device, or multilingual use cases, where legitimate users are more likely to fail authentication even though no security issue is present.
Failure mechanism: The control asks the user to recall, copy, or re-enter a secret or short-lived code, so the authentication step itself becomes a cognitive and operational hurdle instead of a transparent access check.
Impact: Users with disabilities, language barriers, fatigue, or age-related limitations may be locked out, pushed toward insecure workarounds, or forced to depend on support staff, which undermines both accessibility and operational resilience.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Covers authentication methods and user-friendly authenticator design for accessible sign-in. |
| Recommendation — Choose accessible, phishing-resistant authenticators that reduce recall and transcription burden. | ||
Practitioner Guidance
What to verify: Test the full sign-in and recovery journey with users who rely on assistive technology, alternate input methods, or slower interaction patterns. Confirm that the fallback path is as usable as the primary path and does not quietly reintroduce the same memory burden.
Decision rule: If access depends on a user remembering a secret or entering a time-sensitive code under pressure, treat that as a usability and accessibility finding, not just an authentication preference. Prioritise a non-cognitive alternative before tuning prompts, timers, or help text.
Practitioner takeaway: A login flow is accessible only when users can complete it independently without having to perform unnecessary recall, transcription, or coordination work at the point of authentication.
Related resources from NHI Mgmt Group
- Why do traditional password-based login flows create accessibility risk?
- Why do passwords and SMS one-time passcodes create risk in remote authentication flows?
- Why do traditional passwords and one time passcodes create ongoing fraud risk?
- When does one-time identity verification create more risk than it removes?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
