Passkeys are one of the most promising accessibility improvements in authentication. They can replace a site-specific password with a device-supported gesture such as a fingerprint, face scan, PIN, or security key. That removes memorization and can reduce phishing. But a passkey button does not make an authentication system accessible by itself.
People experience authentication as a chain: discover the option, understand it, create a credential, use it on another device, recover when something changes, and choose a fallback when the preferred method is unavailable. A failure anywhere in that chain is a locked door.
What WCAG 2.2 actually asks for
WCAG 2.2 Success Criterion 3.3.8, Accessible Authentication (Minimum), says an authentication step must not require a cognitive function test unless an allowed alternative or assistance mechanism is available. Remembering a password, solving a puzzle, or manually transcribing a one-time code can be a cognitive function test.
Password managers, browser autofill, copy and paste, and WebAuthn can provide the required assistance or alternative. The criterion applies to every step in a multi-step process, including account recovery. A compliant first screen does not rescue an inaccessible second factor.
Passkeys help with memory, not every barrier
A well-designed passkey flow can remove password recall and code transcription. It may also let users rely on familiar device accessibility settings. Yet the surrounding interface can introduce new problems.
- The passkey option is hidden behind an unlabeled icon or an ambiguous phrase such as "Use another method."
- Instructions describe a visual location or biometric gesture without explaining alternatives.
- A QR code is the only cross-device path and has no usable fallback.
- The browser or operating-system dialog appears without prior context, leaving screen-reader users unsure why focus moved.
- Account recovery falls back to security questions, memory tests, or manual support with no accessible channel.
- The service assumes every user owns a second device, can use biometrics, or can scan a code.
These are journey design failures, not flaws in the cryptography. Security and accessibility are strongest when users have more than one secure, understandable route.
Design a clear method chooser
Present authentication methods as named actions with short explanations: "Use a passkey," "Email me a sign-in link," or "Use password and authenticator." Keep the same names through setup, login, settings, and recovery. Explain what will happen before invoking a platform dialog.
Do not rank methods only by visual prominence. A secondary method that is technically present but difficult to find may not function as a practical alternative. Let users return to the chooser without losing their email address or restarting the entire process.
Make password and OTP fallback genuinely usable
Passwords remain a valid accessible method when browsers and password managers can identify and fill the fields. Do not block paste. Use standard HTML inputs, persistent labels, and correct autocomplete tokens. For one-time codes, allow the entire code to be pasted and support autofill instead of forcing users through six separate boxes.
<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="username">
<label for="password">Password</label>
<input id="password" name="password" type="password"
autocomplete="current-password">
<label for="code">Verification code</label>
<input id="code" name="code" inputmode="numeric"
autocomplete="one-time-code">A segmented OTP interface can look polished while making paste, correction, and screen-reader navigation harder. One input is usually simpler. If the visual design must segment the digits, keep one semantic input underneath and test it across supported assistive technology.
Treat magic links as a handoff, not an escape hatch
Magic links reduce memory demand, but they create a context switch into email. State where the link was sent, how long it remains valid, whether the user can safely open it on another device, and how to resend or change the address. Preserve the original task when the user returns.
Avoid short time limits where security does not require them. If a link expires, explain that in text and provide a direct way to request another. Do not show a generic "invalid token" page that strands the user.
Build recovery before launch
Recovery is often the least tested and most consequential path. People change phones, lose security keys, clear synced credentials, change email addresses, and cannot always use the biometric method they used during enrollment.
- Offer more than one recovery method and explain the tradeoffs before the user needs them.
- Let users register multiple passkeys or security keys where the platform supports it.
- Provide accessible recovery codes that can be copied, downloaded, printed, and regenerated.
- Avoid knowledge questions based on personal history or exact spelling.
- Make human support reachable and train support staff not to disable accessibility accommodations as suspicious behavior.
Test the matrix, not just the happy path
Authentication crosses your interface, browser UI, operating-system UI, email or messaging apps, identity providers, and sometimes another device. No single browser test covers that system.
- Keyboard-only: create, use, cancel, retry, switch methods, and recover.
- Screen reader: verify labels, instructions, focus transitions, errors, timeouts, and success messages.
- Zoom and reflow: test platform prompts and method choosers at 200 and 400 percent.
- Cognitive load: test whether instructions are short, stable, and available while the user acts.
- Device change: attempt login without the original phone, biometric, or synced account.
- Failure states: expired link, wrong code, unavailable authenticator, cancelled passkey prompt, and rate limiting.
Use our accessible forms guide for labels and errors, then test the complete authentication journey with the WCAG 2.2 checklist.
The bottom line
Passkeys can make authentication more accessible, but only when they are one understandable path inside a resilient system. Preserve autofill and paste, offer secure alternatives, design recovery with the same care as login, and test every handoff. The goal is not a passwordless screen. It is an account the user can reliably enter and recover.
Sources
W3C WAI: Understanding SC 3.3.8 Accessible Authentication (Minimum)