From passwords and two-factor authentication to passkeys and magic links, login flows are essential gatekeepers of digital life. Yet for many users—especially people with disabilities—these flows can become frustrating or even impossible barriers. This review synthesizes the best available literature, guidelines, and expert commentary into a single narrative: what we know, what we don’t, and what to do next.
Why Accessibility in Authentication Matters
Authentication is often the very first interaction a user has with a digital product. If it fails to be inclusive, users may never get through the door. The Web Content Accessibility Guidelines (WCAG) 2.2 added two success criteria directly addressing this problem: Accessible Authentication (Minimum) and Accessible Authentication (Enhanced). These require that at least one login method must not demand cognitive function tests—such as memorizing or transcribing secrets—without alternatives.
This aligns with the NIST Digital Identity Guidelines (SP 800-63B), which explicitly include usability and equity considerations. Security that people cannot use is not security at all. Accessibility and usability are no longer optional extras; they are part of the baseline requirement.
What the Research Community Has Found
- Passwords and dyslexia: A study by Ophoff et al. (2021) shows that password recall and transcription impose disproportionate barriers on users with dyslexia.
- 2FA usability experiments: Reese et al. (2019) evaluated five types of two-factor authentication in a two-week field study. They found significant differences in setup complexity, day-to-day usability, and error rates.
- Consistency gaps: Lyastani et al. (2023) surveyed 2FA across top websites and found inconsistent terminology, UI, and placement.
- Screen reader authentication: Recent work by Akanda et al. (2025) reveals how OTPs, push approvals, phone calls, and even FIDO flows break down for screen reader users.
- Meta-analyses of MFA: Das et al. (2019) reviewed 623 multi-factor authentication papers and found that fewer than 10% included user-focused evaluation.
Outside academia, practitioners like the Nielsen Norman Group have shown that passwordless systems (like passkeys and OTPs) can reduce friction, but they still need careful attention to context, connectivity, and recovery flows.
Comparing Methods
Passwords
Passwords remain the default but are fraught with accessibility problems. Users must remember them, type them accurately, and often meet arbitrary complexity rules. People with dyslexia, cognitive impairments, or motor disabilities are disproportionately burdened. Simple design choices help: allowing users to paste their passwords into password fields can ensuring compatibility with password managers, providing a “show password” toggle, and not enforcing position-based character entry can go a long way. WCAG explicitly calls out paste-blocking as a failure.
One-Time Passcodes (OTPs)
OTPs delivered via SMS or authenticator apps are common as a second factor. They improve security but create hurdles: codes expire quickly, require transcribing between devices, and can be visually or motor challenging. Mitigations include supporting autofill, announcing countdown timers for screen readers, and providing alternatives such as push approvals. The UK’s NCSC encourages phishing-resistant alternatives when possible.
Push Approvals
Push notifications remove transcription and are easy to complete with a single tap. But they carry risks of “blind approval,” where users click “approve” without scrutiny. Accessibility depends on clear, distinguishable notifications that identify the requesting service and provide an obvious decline option.
Security Keys & WebAuthn
Security keys (like YubiKeys) and WebAuthn offer phishing resistance and minimal memory burden—just “touch the key.” Yet setup can be complex, device compatibility can be limited, and blind users often face unlabeled prompts. The FIDO Alliance UX Guidelines (PDF) offer strong recommendations.
Passkeys
Passkeys – synchronized or device-bound cryptographic credentials – are designed to replace passwords. They integrate with platform biometrics and PINs, reusing accessible OS-level authentication. Studies such as Büttner & Gruschka (2025) compare device-bound versus synced passkeys, showing that usability and recovery mechanisms still need careful thought.
Magic Links
Email-based magic links may be the simplest accessible option. They remove memory and transcription entirely—users just click. WCAG Technique G218 cites this explicitly as sufficient for Accessible Authentication.
Cross-Cutting Accessibility Considerations
When evaluating different authentication methods, it’s important to recognize that accessibility is not only about the specific mechanism (password, passkey, or OTP) but also about how the entire experience is designed and presented. Several recurring themes emerge across the literature and standards, each of which can make the difference between an inclusive login flow and a frustrating barrier.
Consistency matters
One of the most common usability and accessibility failures in authentication is inconsistency. A lack of consistency between websites, between steps in the same flow, or even between the terminology used in the interface and the terms used in user support documentation. For example, some services call their extra layer of protection “two-step verification,” others call it “two-factor authentication,” and still others refer to “login approvals.” To the average user, and especially to users with cognitive impairments, dyslexia, or memory challenges, these inconsistencies increase cognitive load. Instead of reusing learned patterns, users must re-learn and re-interpret each site’s unique wording and design. A consistent approach—both internally within a product and aligned with external conventions—reduces confusion and helps users build reliable mental models of the process.
Screen reader operability is key
Accessibility also hinges on whether assistive technologies can correctly perceive and operate the login process. Every interactive element—buttons, timers, links, error messages, status updates—needs to be clearly labeled and properly announced to a screen reader. Without these cues, blind or low-vision users may be left guessing which control to activate, whether a code has been accepted, or how much time remains before a one-time code expires. Misplaced focus, unlabeled controls & icons, or dynamic updates that aren’t programmatically exposed can render the flow unusable. Designing with semantic HTML, adding ARIA where needed, and thorough testing with screen readers like NVDA, JAWS, and VoiceOver ensures that the login experience is functionally equivalent for all.
Recovery is part of accessibility
Too often, accessibility discussions stop at the point of initial login and ignore what happens when a user gets locked out. Yet recovery is a critical part of the user journey, and for people with disabilities, it is often the most fragile link. Many systems still rely on CAPTCHAs, complex security questions, or multi-step puzzle-like processes for account recovery. These approaches can create insurmountable barriers for users with cognitive or motor impairments, as well as for screen reader users. Accessible recovery flows should always include multiple paths—such as email, phone, or secondary authenticator options—and must avoid making memory or puzzle-solving the sole fallback. Recovery should be designed with the same rigor and inclusivity as initial sign-in.
Education and language
Finally, the words we use to explain authentication matter. Newer methods like passkeys or WebAuthn can sound technical and intimidating if presented in jargon-heavy language. Similarly, even familiar terms like “token” or “factor” may confuse users who aren’t security professionals. Using plain language—“sign in with your device’s face recognition,” or “click the link we send to your email”—helps reduce barriers. Providing short, simple explanations alongside options empowers users to make informed choices without being overwhelmed. Clear error messages, concise instructions, and culturally sensitive translations all contribute to making the process understandable to a wide audience.
A Practical Accessible Authentication Stack
Here are our examples of what makes accessible authentication:
Provide at least one option that does not require memory or transcription.
Every authentication system should offer a way to log in that does not require remembering or transcribing information. Modern implementations of this principle include Apple’s passkeys and Google’s passkey adoption across accounts. Apple users can authenticate with Face ID, Touch ID, or a device PIN—all of which are built into iOS and macOS accessibility features. Google similarly allows passkey sign-in across devices, reducing reliance on typed passwords. For users who cannot manage complex text entry, email-based magic links (used by Slack, Medium, and Notion) provide a one-click way to access accounts that aligns with WCAG’s “Accessible Authentication” success criteria.
Support paste, autofill, and password managers for traditional fields.
Blocking paste or disabling browser autofill directly conflicts with accessibility requirements. Apple’s Safari and iCloud Keychain, Google Chrome’s password manager, and Microsoft Edge all provide secure, integrated autofill experiences. By designing input fields to allow paste and autocomplete attributes, services like GitHub and Twitter (X) make it easy for users to insert long, complex credentials with assistive technology or password managers. This approach removes barriers for users with cognitive or motor impairments.
Offer multiple two-factor authentication methods.
Single-channel two-factor authentication often excludes users. Google leads by example, offering a wide spectrum of second factors: app-based codes, SMS, push notifications, and security keys. Microsoft 365 allows both authenticator app notifications and phone calls as alternatives, supporting users who may struggle with time-based codes. By contrast, services that only permit SMS codes risk excluding users with unreliable mobile coverage, vision impairments, or difficulty entering short-lived codes. The lesson is clear: accessibility improves when users can choose the factor that works for them.
Validate the entire experience with assistive technology.
Ensure you’ve tested your authentication, preferably with real users. Apple regularly showcases how Face ID integrates with VoiceOver, ensuring blind users receive audio prompts during biometric authentication. Google’s accessibility engineering team publishes guidance on testing login experiences with screen readers such as TalkBack and NVDA. These efforts highlight that real-world testing uncovers issues that standards alone cannot—for example, unlabeled buttons, timers that aren’t announced, or error messages that vanish too quickly for a screen reader to catch. Organizations should conduct similar AT-based validation before rolling out login updates.
Design account recovery with inclusivity in mind.
Account recovery is often the weakest link for accessibility. Google provides layered recovery options—backup codes, recovery email addresses, phone verification, or passkeys—so no single path becomes a barrier. Apple ID recovery includes trusted devices and recovery contacts, which can be set up in advance and accessed if the primary method fails. These real-world implementations show that inclusive recovery is possible and should be prioritized. Systems that still rely on inaccessible CAPTCHAs or obscure “security questions” not only frustrate users but also violate modern accessibility principles.
Together, these practices create an authentication system that is both secure and inclusive. They also demonstrate that accessibility is not hypothetical: the world’s largest platforms have already embedded these recommendations into their design.
