WCAG 3.3.8: Accessible Authentication (Minimum)
Signing in should never depend on your memory or puzzle-solving ability. This Level AA criterion, new in WCAG 2.2, says no step of a login may require a cognitive function test — remembering a password, transcribing a code, solving a CAPTCHA — unless there is an accessible alternative or a mechanism to help. In practice it comes down to one habit: let password managers and paste do the work.
The success criterion, in full
A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following: an alternative authentication method that does not rely on a cognitive function test; a mechanism available to assist the user in completing the cognitive function test; the test is to recognize objects; or the test is to identify non-text content the user provided (personal content).
Why accessible authentication matters
Authentication is the gate to everything else — your bank, your health records, your government services. When that gate demands memory or puzzle-solving, it locks out the people least able to provide it. Someone with a memory impairment cannot reliably recall a complex password. Someone with dyslexia struggles to transcribe a string of characters correctly. Someone with a cognitive or learning disability may be unable to decode a distorted-text CAPTCHA at all. The task is not made harder for them — it can be made impossible.
3.3.8 reframes the problem: the barrier is not the user's memory, it is the design that insists on testing it. The fix is rarely to remove security — it is to let tools carry the cognitive load. A password manager remembers the secret; the browser fills the one-time code; a passkey replaces the memory test with a device tap. These are wins for everyone: fewer resets, fewer lockouts, and faster, less error-prone sign-in across the board. It is also a legal target — WCAG 2.2 AA is the reference standard for the DOJ Title II rule and the European Accessibility Act.
What counts as a cognitive function test
A cognitive function test is any task that relies on the user performing a mental operation — remembering, transcribing, calculating, or puzzle-solving. If any single step of your sign-in flow requires one, that step must meet one of the exceptions below.
Remembering a password or passphrase
Recalling a memorized secret is a memory test. It is allowed only because two of the exceptions almost always apply: the field supports password managers and copy-paste, so the user never has to recall or transcribe anything themselves.
Transcribing a one-time code by hand
An SMS or authenticator code that the user must read and retype is a transcription test. It passes only if the user can paste the code, or if it is auto-filled, so they are not forced to hold digits in working memory and copy them character by character.
Solving a puzzle or traditional CAPTCHA
Identifying distorted text, picking every image with a traffic light, or doing arithmetic are classic cognitive function tests. These fail 3.3.8 unless an alternative authentication method that is not a puzzle is offered, or the object-recognition / personal-content exception applies.
Reproducing a pattern, gesture, or spatial sequence
Redrawing a swipe pattern, clicking points in a remembered order, or repeating a gesture relies on recall and is a cognitive function test. Offer a method that does not depend on memory instead.
The four exceptions
A step containing a cognitive function test still passes 3.3.8 if it provides at least one of these. Only the first two — Alternative and Mechanism — apply at every level; Object Recognition and Personal Content are the two that the AAA version (3.3.9) removes.
1. Alternative
Another authentication method that is not a cognitive test.
If any step relies on a cognitive function test, provide a different way to authenticate that does not. Passkeys (WebAuthn), a magic email link, or a link that signs the user in on a trusted device all satisfy this — the user has a route through that never asks them to remember or solve anything.
2. Mechanism
A mechanism is available to help complete the cognitive step.
The step can remain a cognitive test if a mechanism assists it. The everyday example is a password field that permits password managers to fill it and does not block paste — the manager does the remembering and typing, so the user does not. This is why never blocking paste on password and one-time-code fields is the single most important thing you can do.
3. Object Recognition
The test only asks the user to recognize common objects.
A test that asks the user to identify everyday objects — 'select the pictures of a bus' — is permitted, because recognizing common things is not the kind of cognitive function this criterion protects. Note this still must meet 1.1.1 for non-text alternatives and be operable, and audio/other paths help low-vision users.
4. Personal Content
The test uses non-text content the user provided.
A test based on content the user themselves uploaded — 'pick the photo you set as your security image' — is allowed, because it draws on the user's own material rather than a general memory or puzzle-solving demand.
The one-line takeaway: a normal password login already meets 3.3.8 through the Mechanism exception — as long as you set the right autocomplete value and never block paste. You break compliance by fighting the tools, not by using passwords.
CAPTCHAs and 3.3.8
CAPTCHAs are the most common way sites fail this criterion. Where a CAPTCHA lands depends entirely on what it asks the user to do:
Fails 3.3.8
- Reading and retyping distorted text.
- Solving arithmetic or a logic puzzle.
- Rotating an image to the "correct" angle.
- Remembering and repeating a sequence.
Can pass 3.3.8
- Recognizing common objects (object exception).
- Identifying content the user uploaded.
- A non-interactive / risk-based bot check.
- Any puzzle plus a non-cognitive alternative path.
The most robust and future-proof choice is a bot-detection method that presents no puzzle at all— a privacy-preserving attestation token, a risk score, or an invisible challenge that only escalates for suspicious traffic. That approach sidesteps the cognitive test entirely and avoids the object-recognition exception's remaining friction for low-vision users. If you must keep an interactive challenge, always pair it with an alternative route such as an email magic link.
Code examples
A password field that meets 3.3.8
The right autocomplete tokens let password managers and browsers fill both fields, and nothing blocks paste — so the mechanism exception is satisfied.
<label for="email">Email</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" />
<!-- No onpaste="return false", no oncopy blocking,
no "enter characters 2, 5 and 8 of your password" -->A one-time code field that can be pasted and auto-filled
autocomplete="one-time-code" lets mobile browsers offer the SMS code, and leaving paste enabled means users can copy it straight from their messages instead of transcribing it.
<label for="otp">Enter the 6-digit code we sent you</label>
<input id="otp" name="otp" type="text"
inputmode="numeric" autocomplete="one-time-code"
pattern="[0-9]*" maxlength="6" />
<!-- Do NOT split into six separate single-character boxes
that reset on paste; a single field pastes cleanly. -->Offering a passkey as the non-cognitive alternative
A passkey (WebAuthn) replaces recall with a device tap or biometric — no memory, no transcription, no puzzle — and provides the alternative exception for any flow that still contains a cognitive step.
<button type="button" id="passkey-signin">
Sign in with a passkey
</button>
<script>
document.getElementById("passkey-signin")
.addEventListener("click", async () => {
// options fetched from your server
const credential = await navigator.credentials.get({
publicKey: options,
})
// send credential to server to verify — user
// authenticated with no cognitive function test
await verifyOnServer(credential)
})
</script>Anti-pattern: a field that blocks paste
This is the classic 3.3.8 failure. Disabling paste removes the mechanism that lets a password manager or the clipboard do the cognitive work, forcing manual transcription.
<!-- DON'T: this fails WCAG 3.3.8 -->
<input id="password" type="password"
onpaste="return false"
oncontextmenu="return false"
autocomplete="off" />Common mistakes
- Blocking paste on password or one-time-code fields, which removes the mechanism that lets managers and the clipboard do the work.
- Setting autocomplete="off" on the password field, stopping password managers from filling it.
- Asking for specific characters of a password ('enter the 2nd, 5th and 8th letters') — a password manager cannot fill this, so it becomes a pure memory test.
- Using a distorted-text or math CAPTCHA with no alternative authentication path.
- Splitting a one-time code into six single-character inputs that discard a pasted value or scatter the digits.
- Requiring the user to re-key a code from an email or SMS with paste disabled.
- Treating security questions ('your first pet's name') as accessible — they are a memory test with no mechanism.
- Assuming an audio CAPTCHA fixes the problem; transcribing spoken characters is still a cognitive function test.
How to test for 3.3.8
- 1
Walk every step of the sign-in flow
List each step a user must complete to authenticate — password, second factor, CAPTCHA, security question. For each, ask: does this require remembering, transcribing, or solving something? Every 'yes' needs an exception.
- 2
Try to paste into every field
Copy some text and attempt to paste it into the password and one-time-code fields. If paste is blocked, the mechanism exception is broken and the step fails.
- 3
Check the field with a password manager
Use a real password manager (e.g. 1Password, Bitwarden, or the browser's built-in) and confirm it offers to fill the fields. If autocomplete="off" or an odd field name stops it, fix the markup.
- 4
Look for a non-cognitive alternative
Where a step is genuinely a cognitive test (a puzzle CAPTCHA, an odd challenge), confirm there is an alternative route — passkey, magic link, or trusted-device sign-in — that avoids it entirely.
- 5
Classify any CAPTCHA
If a CAPTCHA is present, decide which bucket it is in: puzzle/transcription (fails without an alternative), object recognition (allowed at AA), or personal content (allowed). Prefer a no-puzzle bot check.
Audit a live login page with the URL Accessibility Auditor and confirm assistive-technology behavior using the Screen Reader Testing Guide.
Related success criteria
3.3.9 Accessible Authentication (Enhanced) — AAA
The stricter partner: the same rule but without the object-recognition and personal-content exceptions, so no recognition test is permitted at all.
3.3.2 Labels or Instructions — A
Clear labels and instructions on the login form help every user understand what is required — the prevention layer beneath accessible authentication.
3.3.3 Error Suggestion — AA
When a login fails, suggest how to recover — while respecting the security exception that keeps sign-in messages generic.
1.1.1 Non-text Content — A
Object-recognition CAPTCHAs still need text alternatives and operable controls — 1.1.1 governs the images themselves.
Browse every criterion in the WCAG Success Criteria hub or work through the full WCAG 2.2 checklist.
Frequently asked questions
What does WCAG 3.3.8 Accessible Authentication (Minimum) require?
WCAG 3.3.8 requires that a cognitive function test — such as remembering a password, solving a puzzle, or transcribing a code — is not required for any step in an authentication process, unless that step provides an alternative that is not a cognitive test, or a mechanism to assist. Object recognition and personal-content tests are also exempt. It is a Level AA success criterion, new in WCAG 2.2.
Is 3.3.8 saying passwords are banned?
No. Passwords are fine, because two exceptions almost always apply. If your password field lets a password manager fill it (via autocomplete="current-password") and you do not block paste, then the user is never forced to remember or transcribe the secret themselves — a mechanism is doing it. Passwords only fail 3.3.8 when you sabotage those helpers: blocking paste, disabling autofill, or forcing manual entry of characters from the password ("type the 3rd and 7th letter").
Do traditional CAPTCHAs fail WCAG 3.3.8?
A CAPTCHA that asks you to read distorted text, solve a puzzle, or do arithmetic is a cognitive function test and fails 3.3.8 unless you offer an alternative that is not a cognitive test. A CAPTCHA that only asks you to recognize common objects ("select all images with a bicycle") is allowed under the object-recognition exception, though it must still meet 1.1.1 and be operable. The most robust answer is a non-interactive or risk-based bot check (e.g. a privacy-preserving token) that presents no puzzle at all.
How is 3.3.8 (Minimum, AA) different from 3.3.9 (Enhanced, AAA)?
They share the same rule but differ in which exceptions apply. 3.3.8 Accessible Authentication (Minimum) is Level AA and allows the object-recognition and personal-content exceptions. 3.3.9 Accessible Authentication (Enhanced) is Level AAA and removes those two, so it does not permit any object-recognition test at all. Meeting AA (3.3.8) is the compliance target for most organizations, including under the European Accessibility Act and DOJ Title II.
Why does allowing paste matter so much for 3.3.8?
Because paste is what turns a memory-and-transcription task into an assisted one. If a user can paste their password from a manager, or paste a one-time code from their SMS app, they never have to hold the secret in working memory or copy it character by character — the mechanism exception is met. Blocking paste (oninput/onpaste preventDefault) removes that assistance and is one of the most common ways sites fail this criterion.
Do passkeys and biometric login satisfy 3.3.8?
Yes. Passkeys (WebAuthn/FIDO2), biometric unlock, and device-based sign-in ask the user to do nothing cognitive — no recall, no transcription, no puzzle — so they meet 3.3.8 outright and are the strongest way to satisfy it. Offering a passkey path is also the cleanest way to provide the "alternative" exception for any flow that does contain a cognitive step.
Does a one-time passcode (OTP) sent by SMS pass 3.3.8?
It can, but only if the user is not forced to transcribe it from memory. Support autocomplete="one-time-code" so mobile browsers can auto-fill it, and never block paste, so the user can copy it directly from their messages. If the code can only be entered by reading and retyping it digit by digit with paste disabled, that is a transcription-based cognitive test and fails.