Skip to main content
Beta: Front-End Checklist is currently in beta. Some issues are still being fixed. Thanks for your patience.

Provide accessible authentication methods

Authentication flows avoid unnecessary cognitive tests and support assistive mechanisms such as password managers, paste, OTP autofill, and passkeys.

Utilities
Quick take
Typical fix time 25 min
  • Do not block paste or password managers in login and recovery flows
  • Prefer passkeys, magic links, device approval, or password-manager-friendly flows
  • Support OTP autofill and paste with appropriate semantics such as `autocomplete="one-time-code"`
  • Avoid CAPTCHA or secondary checks that require memorizing or transcribing information without an alternative
Why it matters: Authentication often becomes the first hard blocker for users with cognitive, motor, low-vision, or speech-input needs. If sign-in, MFA, or recovery relies on memorization or transcription with no assisted path, the user may be locked out before they can access the product at all.

Rule Details

Authentication should not depend on the user's ability to memorize, transcribe, or manually reproduce information when an assistive path is feasible. Good accessible authentication usually improves security too, because it works with password managers, device-based verification, and passkeys rather than against them.

Code Example

<!-- Better: password-manager and OTP-friendly fields -->
<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="username webauthn">
 
<label for="password">Password</label>
<input
  id="password"
  name="password"
  type="password"
  autocomplete="current-password">
 
<label for="otp">Verification code</label>
<input
  id="otp"
  name="otp"
  inputmode="numeric"
  autocomplete="one-time-code">
function VerifyCodeField({
  onSubmit,
}: {
  onSubmit: (code: string) => void
}) {
  return (
    <form
      onSubmit={(event) => {
        event.preventDefault()
        const formData = new FormData(event.currentTarget)
        onSubmit(String(formData.get('otp') ?? ''))
      }}
    >
      <label htmlFor="otp">Enter the verification code</label>
      <input
        autoComplete="one-time-code"
        id="otp"
        inputMode="numeric"
        name="otp"
        type="text"
      />
 
      <button type="submit">Continue</button>
    </form>
  )
}
<!-- Better: offer a non-memory-dependent alternative -->
<button type="button">Continue with a passkey</button>
<button type="button">Email me a sign-in link</button>

Why It Matters

Many authentication patterns are built around unnecessary friction: blocked paste, custom OTP widgets that break autofill, CAPTCHA transcription, or backup questions that require memory instead of possession-based proof.

  • cognitive barriers prevent account access before the user can do anything else
  • password-manager hostility leads to weaker, reused passwords
  • speech, switch, and keyboard-only users face more effort when copy/paste and autofill are disabled
  • recovery and MFA steps often fail even when the main login form looks acceptable

Best Practices

Support assisted entry

Authentication should work with:

  • password managers
  • pasted credentials and codes
  • OS/browser OTP autofill
  • passkeys or device approval when available

Do not split a one-time code into a widget that breaks standard autofill unless you have verified the real browser behavior.

Provide a non-memory-dependent path

At least one viable route through sign-in, MFA, and recovery should avoid a cognitive function test. Good examples include:

  • passkeys
  • approval on a trusted device
  • magic links
  • password-manager-assisted password entry

Keep anti-abuse controls proportional

If you use CAPTCHA or other abuse mitigations in auth flows, provide an alternative path that does not force memorization or transcription. Accessibility and abuse prevention must be designed together, not as competing concerns.

Standards

  • This rule maps to WCAG 2.2 Success Criterion 3.3.8 Accessible Authentication (Minimum).
  • The practical goal is not "less security"; it is at least one viable path that does not depend on a cognitive function test.

Exceptions

  • Re-entering a newly created password can be a valid security exception when the system does not reveal the password back to the user.
  • MFA is compatible with this rule, but the user still needs at least one practical path that does not rely on memorizing or transcribing information.
  • Accessibility does not require removing security; it requires choosing security controls that users can actually complete.

Verification

Automated Checks

  • Search auth flows for blocked paste handlers, OTP widgets, and missing autocomplete attributes.
  • Verify username, current-password, new-password, and one-time-code fields use appropriate semantics.

Manual Checks

  • Test sign-in with a password manager.
  • Paste an OTP or let the browser autofill it where supported.
  • Exercise recovery and MFA flows, not only the primary login form.
  • Fail if the only available path requires memorizing, transcribing, or solving a cognitive test without an assisted alternative.

Use with AI

Copy these prompts to use with your AI assistant, or install the MCP server to use directly from Claude, Cursor, or Windsurf.

Check

Verify implementation

Review login, MFA, password reset, and account recovery for accessible authentication problems. Flag blocked paste, password-manager hostility, manual transcription requirements, inaccessible OTP handling, and CAPTCHA or knowledge checks without a compliant alternative.

Fix

Auto-fix issues

Add password-manager-friendly fields, support paste and OTP autofill, and provide at least one authentication path that does not depend on a cognitive function test.

Explain

Learn more

Explain WCAG Accessible Authentication, why memorization and transcription are barriers, and how passkeys, password managers, OTP autofill, and device approval improve both accessibility and security.

Review

Code review

Review authentication pages, MFA steps, recovery flows, and security controls related to Provide accessible authentication methods. Flag exact steps that require memorization, transcription, blocked assistive tooling, or inaccessible fallback paths.

Sources

References used to support the guidance in this rule.

Further Reading

Tools and supplementary material for exploring the topic in more depth.

WebAuthn.io
webauthn.ioTool

Rules that often go hand-in-hand with this one.

Allow pasting into form inputs

Users should be able to paste content into form fields to improve usability and reduce errors.

Accessibility
Secure password input fields

Password fields implement security best practices including proper autocomplete, show/hide toggle, and strength indicators.

Security
Protect public forms with CAPTCHA

Public forms that accept user input without authentication must include bot protection to prevent spam, credential stuffing, and automated abuse.

Security
Prevent data loss from session timeouts

Users are warned before session expiry, can extend time when appropriate, and can re-authenticate or resume work without losing entered data.

Accessibility

Was this rule helpful?

Your feedback helps improve rule quality. This stays internal for now.

Loading feedback...
0 / 385