WCAG 3.3.9: Accessible Authentication (Enhanced)
Logging in should prove who you are, not how good your memory or puzzle solving is. At Level AA, 3.3.8 banned cognitive function tests with four escape hatches. This AAA criterion keeps the same rule and closes the two picture-based hatches: object-recognition tests and personal-content tests no longer count as exceptions. Only a true alternative or an assisting mechanism will do.
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:Alternative — Another authentication method that does not rely on a cognitive function test.Mechanism — A mechanism is available to assist the user in completing the cognitive function test.
Compare 3.3.8: identical opening, but its additional Object Recognition and Personal Content exceptions are absent here. That two-line deletion is the entire difference between AA and AAA authentication.
Who this helps
Authentication is the front door to everything — banking, healthcare, email, government services. A cognitive test at that door doesn’t inconvenience some users; it locks them out entirely.
People with memory impairments
Recalling passwords, PINs, or security-question answers may be impossible. Passkeys, magic links, and password-manager support remove recall from the flow altogether.
People with dyslexia and dyscalculia
Transcribing a one-time code or distorted CAPTCHA string means holding and reordering characters — precisely the operation these disabilities disrupt. Paste and auto-fill eliminate the transcription.
People with visual-processing differences
This is who the AAA tightening protects: users who cannot reliably identify pictured objects. At AA an image-selection CAPTCHA is an allowed exception; at AAA it must have a non-cognitive alternative.
Everyone under stress
Cognitive capacity drops with age, fatigue, medication, and anxiety. Login friction is a leading cause of abandoned accounts and support calls — non-cognitive authentication is simply better product design.
The requirement, AA vs AAA
A cognitive function test is any task requiring the user to remember, manipulate, or transcribe information, or to solve problems: memorized passwords, retyped one-time codes, CAPTCHA puzzles of every flavor, pattern gestures, mental arithmetic, security questions. The rule applies to every step of the process — login, two-factor, bot checks, and recovery included. Side-by-side, the exception lists:
| Exception | 3.3.8 Minimum (AA) | 3.3.9 Enhanced (AAA) |
|---|---|---|
| Alternative non-cognitive method | Allowed | Allowed |
| Assisting mechanism (paste, autofill) | Allowed | Allowed |
| Object recognition (“select the buses”) | Allowed | Not allowed |
| Personal content (your uploaded photo) | Allowed | Not allowed |
Practical consequence: any image-based CAPTCHA, security image check, or “pick your photo” verification that stood on its own at AA must, at AAA, be either replaced by a non-cognitive method or paired with one the user can freely choose instead.
Pass and fail examples
✓ Passes 3.3.9
- Passkey sign-in via WebAuthn, with device biometrics handling identity — no recall, no transcription.
- Email magic link as an always-available alternative beside the password form.
- A password field with autocomplete="current-password" and unrestricted paste — the manager is the mechanism.
- Two-factor via push approval (“Tap Yes to sign in”) instead of typed codes.
- Bot protection using risk-based, non-interactive checks rather than any puzzle.
✗ Fails 3.3.9
- An image-grid CAPTCHA (“select all traffic lights”) as the only route in — passes 3.3.8, fails 3.3.9.
- A “click your security image” step relying on the personal-content exception that AAA removes.
- A password field that blocks paste and autofill, with no passkey or magic-link alternative.
- Recovery flows gated solely on memorized security questions.
- An OTP screen that disables paste and ignores autocomplete="one-time-code", forcing digit-by-digit transcription.
Code: conforming login patterns
Manager-friendly credentials plus a passkey alternative
The password path conforms through the mechanism exception; the passkey button provides the alternative for everything else in the flow.
<form action="/login" method="post">
<label for="user">Email address</label>
<input id="user" name="user" type="email"
autocomplete="username webauthn" />
<label for="pass">Password</label>
<!-- Never block paste; let managers fill it -->
<input id="pass" name="pass" type="password"
autocomplete="current-password" />
<button type="submit">Sign in</button>
</form>
<button type="button" id="passkey-btn">
Sign in with a passkey instead
</button>
<a href="/login/magic-link">Email me a sign-in link</a>A passkey request with WebAuthn
document.getElementById("passkey-btn")
.addEventListener("click", async () => {
const options = await fetch("/webauthn/options").then(r => r.json())
// The platform handles identity via biometric or device PIN —
// no memory, transcription, or puzzle involved.
const credential = await navigator.credentials.get({
publicKey: options,
})
await fetch("/webauthn/verify", {
method: "POST",
body: JSON.stringify(credential),
})
})One-time codes that fill themselves
If you keep OTP, make transcription unnecessary: autocomplete="one-time-code" lets mobile platforms offer the received code, and paste must keep working.
<label for="otp">6-digit code from your authenticator app</label>
<input id="otp" name="otp" inputmode="numeric" pattern="[0-9]{6}"
autocomplete="one-time-code" />
<!-- ✗ Never do this on an OTP or password field:
onpaste="return false" -->Common failures
- Relying on an object-recognition CAPTCHA as the sole bot check — the exception that made this legal at AA does not exist at AAA.
- Security-image or 'pick the photo you uploaded' verification steps with no non-cognitive alternative offered.
- Blocking paste or autofill on password, OTP, or security-answer fields, destroying the assisting mechanism that would otherwise conform.
- Asking users to type specific characters of their password ('3rd, 6th and 9th'), which defeats password managers by design.
- Cross-device flows that display a code on one screen to be manually retyped on another, with no copy or push-approval path.
- Recovery and account-verification steps built entirely on memorized security questions.
- Offering a passkey alternative but hiding it behind the failed cognitive step — the alternative must be reachable without completing the test.
How to test for 3.3.9
- 1
Map every step of every authentication flow
Login, registration, two-factor, bot checks, re-authentication, and recovery. The criterion applies per step — one puzzle anywhere in the chain scopes it in.
- 2
Classify each step: is it a cognitive function test?
Does it require remembering, transcribing, calculating, solving, or recognizing anything — including common objects and the user's own uploaded content? At AAA, image recognition counts as a cognitive test with no exemption.
- 3
Test the assisting mechanism honestly
Fill the login with a real password manager, and paste into every password and code field from the clipboard. Check autocomplete attributes are present and nothing intercepts paste events. If the manager can complete the step end to end, the mechanism exception is met.
- 4
Verify the alternative is real and reachable
Where a cognitive step remains, confirm a non-cognitive method (passkey, magic link, push approval) is offered on the same screen or earlier — not gated behind completing the very test it is meant to replace.
- 5
Run the whole flow with assistive technology
Complete authentication using only a keyboard and then with a screen reader. Confirm any third-party auth widgets (CAPTCHA iframes, SSO popups) are themselves operable — an inaccessible widget can fail this and several other criteria at once.
Pair this with the AA baseline in our 3.3.8 guide and the full WCAG 2.2 checklist.
Relationship to 3.3.8 and 3.3.7
WCAG 2.2 added three criteria to Guideline 3.3, and they work as a set. 3.3.7 Redundant Entry (A) stops processes from asking for the same information twice — cognitive load before authentication. 3.3.8 Accessible Authentication (Minimum) (AA) is the compliance target most laws reference, with its four exceptions. 3.3.9 is the destination: authentication with no cognitive gate that lacks a genuine way around it.
The upgrade path is concrete: a site meeting 3.3.8 typically reaches 3.3.9 by swapping its image CAPTCHA for a risk-based or non-interactive bot check and adding one non-cognitive sign-in option such as passkeys. Any CAPTCHA you retain also owes a text alternative under 1.1.1 Non-text Content (A) — accessible authentication and accessible bot defense are the same project.
Frequently asked questions
What does WCAG 3.3.9 Accessible Authentication (Enhanced) require?
It requires that no step of an authentication process relies on a cognitive function test — remembering a secret, transcribing characters, solving a puzzle — unless one of exactly two conditions holds: an alternative authentication method exists that is not a cognitive function test, or a mechanism (like password manager support and paste) is available to assist the user through the step. It is a Level AAA success criterion, new in WCAG 2.2, sitting directly above 3.3.8 Accessible Authentication (Minimum).
What is the exact difference between 3.3.9 and 3.3.8?
The rule is word-for-word the same; the exception list shrinks. 3.3.8 (Level AA) permits four escapes: an alternative method, an assisting mechanism, tests based on recognizing common objects, and tests based on personal content the user provided (like a chosen security image). 3.3.9 (AAA) keeps only the first two. Object-recognition CAPTCHAs ('select all bicycles') and personal-content checks, which pass at AA, fail at AAA unless a non-cognitive alternative or assisting mechanism is also offered.
Why does AAA remove the object-recognition exception?
Because recognizing objects is still a cognitive task, and for some users a hard one. People with agnosia or significant visual-processing differences may be unable to identify pictured objects; images are often small, low-quality, or culturally unfamiliar ('select the American-style crosswalks'); and memory-based personal-content checks still lean on recall. The AA exceptions were a pragmatic compromise for the wide web. AAA represents the full goal: authentication that demands no test of cognitive function at all.
Do passwords automatically fail 3.3.9?
No. Remembering a password is a cognitive function test, but the 'mechanism' exception survives at AAA: if your login field works with password managers (autocomplete="current-password"), never blocks paste, and doesn't force partial-character entry, the manager does the remembering and the step conforms. What fails is sabotaging that support — paste blockers, autofill-hostile fields, 'enter the 2nd, 5th and 9th character of your password' schemes — without offering a non-cognitive alternative like a passkey.
What login designs satisfy 3.3.9 outright?
Methods with no cognitive test anywhere: passkeys (WebAuthn/FIDO2) using device biometrics or PIN handled by the platform, magic sign-in links sent by email, push-approval in an authenticator app (tap to approve, not transcribe), OAuth federation to a provider that itself conforms, and hardware security keys. Any one of these as an always-available option also acts as the 'alternative' that lets you keep a traditional password path alongside.
Are two-factor codes (OTP) allowed under 3.3.9?
Yes, if no step forces recall or transcription. An SMS or TOTP code passes when the field supports autocomplete="one-time-code" auto-fill and paste works, so the user can move the code without retyping it digit by digit. Cross-device flows where the user must read a code on one screen and type it on another with no copy path are transcription tests and fail. Push-based approval avoids the problem entirely.
Does 3.3.9 apply to things like security questions?
Yes. 'What was your first pet's name?' is a memory-based cognitive function test. At AAA it conforms only if an assisting mechanism applies (the answer field allows paste and password-manager fill, letting users store answers) or a non-cognitive alternative route exists. Security questions are also weak security practice; replacing them with passkeys or email-verified recovery satisfies both the accessibility and security arguments at once.
Related Success Criteria
Input errors are automatically detected and described to the user.
Labels or instructions are provided when content requires user input.
Input error suggestions are provided when errors are detected.
Important transactions can be reversed, checked, or confirmed.
Context-sensitive help is available.