Home WCAG

WCAG 3.3.8 Accessible Authentication (Minimum)

Authentication must not depend solely on a cognitive function test (memorise, transcribe). New in WCAG 2.2 at Level AA. Affects password fields, captcha challenges, and SMS code transcription.

Normative spec
https://www.w3.org/TR/WCAG22/#accessible-authentication-minimum
Last verified
Byline
Editorial team

What 2.2 added

Success Criterion 3.3.8 Accessible Authentication (Minimum) is one of the nine success criteria added in WCAG 2.2 (October 2023). It requires that the authentication path does not rely solely on a cognitive function test — memorising a password, transcribing a six-digit SMS code, recognising puzzle pieces in an image-based captcha — unless one of the following is also available:

  1. Alternative. Another authentication method that does not rely on a cognitive function test.
  2. Mechanism. Help to complete the test (password manager, browser autofill, copy-paste from SMS).
  3. Object recognition or personal-content recognition (the user identifies known images of their own pets — permitted as a non-cognitive test).
  4. The cognitive test is to recognise objects or non-text content the user provides (drawing they made, photo of pet).

The Level AAA companion 3.3.9 Accessible Authentication (Enhanced) removes alternative #3 and #4: any cognitive function test is a failure regardless of recognition exemption.

Why this matters

Cognitive function tests fail users with:

  • Dyslexia (transcribing 6-digit codes mis-character-orders).
  • ADHD (working-memory load during a multi-step login).
  • Memory impairments (post-stroke, dementia, age-related).
  • Cognitive fatigue (chemotherapy patients, post-COVID brain fog).

About 17% of adults report a “memory or concentration condition that lasts more than 6 months” per CDC’s 2023 disability survey. Many never report it as a disability but disable the affected authentication paths regardless.

What a passing implementation looks like

The user can sign in without typing the password from memory. Concretely, on every login form:

  • The password field is type="password" so the password manager fills it.
  • The password field has autocomplete="current-password" so the autofill heuristic recognises it.
  • The username field has autocomplete="username".
  • One-time codes are pasted, not transcribed: autocomplete="one-time-code" enables iOS / Android keyboard suggestion banners.
  • WebAuthn / passkey is offered as an alternative.

For high-stakes flows (banking, healthcare):

  • WebAuthn is the recommended primary method; password is a fall- back.
  • If a captcha is required, it uses a non-cognitive method (Cloudflare Turnstile, hCaptcha invisible mode) or has a captcha-free alternative.

Pitfalls that make 3.3.8 fail

  • type="text" masking password input via JS. Disables password-manager autofill. Use type="password".
  • autocomplete="off" on a password field. Some browsers still autofill, but security tools penalise the form. Use autocomplete="current-password" or new-password.
  • Pasting disabled in the password or OTP field. A frequent mistake driven by misreading “improves security”. Pasting must remain enabled to satisfy 3.3.8.
  • CAPTCHA that requires identifying traffic lights or bicycles. Unless an audio or text alternative is present, this is a cognitive function test on top of a perceptual one. Use invisible / risk-based captchas first.
  • 6-digit SMS code without autocomplete="one-time-code" and without inputmode="numeric". Users have to switch keyboard, read the SMS, transcribe by hand.
  • “Picture login” with random pictures. Personal-content recognition is exempt — random pictures from a set are not.

WebAuthn as the canonical 3.3.8 path

WebAuthn / passkey support reached interop in 2023 across Chromium, WebKit, and Gecko, on macOS / iOS / Android / Windows. A passkey login is a single biometric prompt — no password, no transcription, no captcha. About 25% of consumer accounts on Big-N sites had a passkey by end of 2024 (FIDO Alliance 2024 report).

<form>
  <label>Email <input type="email" name="email" autocomplete="username webauthn"></label>
  <button type="submit">Sign in with passkey</button>
</form>

The webauthn token in autocomplete (added 2023) signals the form to surface available passkeys in the browser autofill UI.

Common pitfalls

  • Forms that compute trust in a long string of cognitive tests. “Type your password, then transcribe a 6-digit code, then drag this puzzle piece.” Each individual gate may pass, but the composite usability collapses. Use one robust factor instead of three weak ones.
  • Password rules that prevent password managers. A maximum length of 16 or rules that disallow paste defeat the very tool the criterion encourages.
  • Implementation that breaks autofill on focus change. Some React libraries re-mount the password field on each render, preventing autofill. Keep the field mounted.

Cross-engine support

The criterion is platform-agnostic. The relevant primitives — autocomplete tokens, WebAuthn API, <input type="password"> — all reached interop years before WCAG 2.2 was published.

Further reading