3.3.8 Accessible Authentication (Minimum)
- Level AA
- Understandable
- New in WCAG 2.2
Summary
Logging in must not force anyone to remember or transcribe something. Remembering a password, copying a code from one place to another, and solving a puzzle are all cognitive function tests, and this criterion says no step of an authentication process may require one unless there is an alternative method, or a mechanism that assists the user, or the test falls under the object recognition or personal content exceptions.
The requirement is new in WCAG 2.2 at Level AA. The subtlety auditors miss most often: an ordinary password field is not automatically a failure. Password entry passes precisely because support for password managers and paste is the assisting mechanism. Block paste or suppress autofill on that field and the mechanism is gone, so the step now requires recall and the criterion fails. The people this protects include those with memory impairments, dyslexia, or cognitive fatigue, and anyone for whom puzzle-style challenges cause genuine anxiety, all of whom are routinely locked out of services by login screens the rest of us merely find irritating.
Official wording
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.
Object Recognition: The cognitive function test is to recognize objects.
Personal Content: The cognitive function test is to identify non-text content the user provided to the website.
EN 301 549 mapping
This success criterion is new in WCAG 2.2. EN 301 549 V3.2.1, the harmonised European standard currently in force, references WCAG 2.1 and contains no clause for it. A revision aligned with WCAG 2.2 is in progress; until it is published and cited in the Official Journal of the EU, this criterion is not part of the harmonised standard.
Checked against EN 301 549 V3.2.1 (2021-03).
In practice
Web
Test the login flow as a password manager user would. Can you paste into the username and password fields? Do the fields accept browser and password manager autofill, or has the author set autocomplete="off" on credentials, intercepted paste events, or split the password across multiple inputs that autofill cannot populate? Any of those removes the mechanism, and typing a memorised password from scratch is exactly the cognitive function test the criterion prohibits.
Partial-password prompts are the classic hard fail: "enter the 3rd, 5th and 7th characters of your password" demands both recall and character counting, and no mainstream password manager can complete it. Unless the site offers a non-cognitive alternative, that step fails.
One-time codes deserve honest treatment. Copying a code from an SMS or email into a field is transcription, which is a cognitive function test. It can still pass, because the code arrives in a place the user can copy from, and copy-paste plus browser OTP autofill (autocomplete="one-time-code" and messaging-based fill) count as assistance. The moment the flow blocks paste on the code field, or the code is displayed somewhere it cannot be copied from (a separate hardware token with no transfer support), the assistance argument collapses and you should grade it a fail.
The cleanest passes avoid the test entirely: magic links sent by email, passkeys and WebAuthn, and third-party OAuth sign-in are all authentication methods with no cognitive function test, and any one of them offered alongside a password satisfies the alternative condition. CAPTCHAs at login need splitting: text-distortion and audio puzzles are cognitive function tests and fail without an alternative, while "select all the traffic lights" style challenges are object recognition and sit inside that exception at this level.
iOS
On iOS the mechanism is Password AutoFill and passkey support. A standard UITextField with the right textContentType (username, password, newPassword) surfaces stored credentials above the keyboard, and that platform integration is what lets a password screen pass. The common failure is a custom secure field, a web view login that strips autofill hints, or a field with paste disabled: iOS stops offering credentials, the user is back to recalling the password, and the step fails.
SMS one-time codes get first-class assistance on iOS: a field marked textContentType = .oneTimeCode lets the system offer the incoming code directly, so the user never transcribes it. Face ID or Touch ID offered alongside a password is a textbook alternative, since biometric unlock involves no memory or puzzle at all. Note the framing: biometrics as the only method raises other concerns, but biometrics as an option next to a manager-friendly password field makes the whole step comfortably conformant.
Android
Android's equivalents are the Autofill framework, Credential Manager, and passkey support. Fields with correct autofill hints (username, password) let stored credentials fill both fields in one tap. Failures mirror iOS: importantForAutofill="no" on credential fields, custom-drawn inputs the framework cannot see, or paste blocked on the password field all strip the mechanism away and leave the user typing from memory.
For one-time codes, the SMS Retriever and user-consent APIs let apps read or offer the incoming code so the user never retypes it, and autofill can populate OTP fields directly; either counts as assistance. Biometric unlock through the platform biometric prompt, offered alongside a credential login, satisfies the alternative condition on its own.
Pass and fail examples
Passes:
- A standard email and password form that accepts paste and password manager autofill: the manager support is the mechanism.
- A login offering "sign in with a passkey" or OAuth alongside the password form: a non-cognitive alternative exists, so the password step is covered regardless.
- An emailed magic link as the sole login method: clicking a link is not a cognitive function test.
- An SMS code the user can copy, filling a field that supports OTP autofill and paste: transcription with genuine assistance.
- An image CAPTCHA asking the user to pick the photos containing bicycles: object recognition exception.
Fails:
- A password field with paste disabled "for security": recall is now required and no mechanism assists it.
- Credential fields with autofill suppressed so password managers cannot fill them, with no alternative sign-in method.
- "Enter the 2nd, 4th and 6th characters of your memorable word" with no manager support and no alternative.
- A distorted-text or audio-puzzle CAPTCHA gating login with no non-cognitive alternative route.
- A verification code shown on one device that must be manually retyped on another, with paste blocked on the receiving field.
Not a fail under this criterion:
- Having to remember or autofill your username or email address: usernames are credentials too, and the same analysis applies, but they are typically autofillable and pasteable, so a normal field passes.
- Object recognition challenges and "pick the photo you uploaded" personal content checks: both exceptions apply at Level AA. The Level AAA sibling, 3.3.9 Accessible Authentication (Enhanced), removes those two exceptions, so flag them as AAA improvements rather than AA failures.
Commonly confused with
- Redundant Entry, SC 3.3.7. Also new in WCAG 2.2 and often tested in the same session. Re-typing non-credential data you already gave earlier in a flow (an address, a booking reference) is a 3.3.7 finding; authentication steps that demand memory or transcription land here.
- Non-text Content, SC 1.1.1. A CAPTCHA earns two separate analyses. Whether it has text alternatives describing its purpose and offers alternative modalities is the 1.1.1 side; whether the puzzle itself imposes a cognitive function test without an alternative is the 3.3.8 side. A CAPTCHA can pass one and fail the other.
- Identify Input Purpose, SC 1.3.5. Missing
autocompletetokens on common input fields is a 1.3.5 finding in its own right. It becomes a 3.3.8 finding only when the missing or suppressed autofill is on a credential field in an authentication step and no other mechanism or alternative saves it. - Security objections. "We block paste to stop attacks" is not an exception. The criterion has exactly four escape routes (alternative, mechanism, object recognition, personal content), and organisational security policy is not one of them. Grade the fail and note the remediation options.
How AUDITSU tests this
AUDITSU's audit walkthrough puts authentication screens through a dedicated set of questions. For each step of the login flow it asks: can you paste into every credential field, do the fields accept a password manager or platform autofill, does any step demand recall or transcription without support, and is at least one non-cognitive alternative (passkey, magic link, OAuth, biometric) on offer? Each question records a pass, fail, or not applicable result with evidence attached, so a blocked paste event or suppressed autofill lands in your report tied to the exact screen and field.
Because EN 301 549 V3.2.1 does not yet include this criterion, AUDITSU tracks it under WCAG 2.2 conformance. When your audit targets the European Accessibility Act, the walkthrough treats 3.3.8 as forward guidance until the revised harmonised standard adopts WCAG 2.2.
For the full guided workflow, see the audit platform.