Accessible Authentication: Logins That Do Not Test Memory or Puzzle Solving

WCAG 2.2 criterion 3.3.8 bans cognitive function tests at login unless an alternative exists. What that means for passwords, codes, and CAPTCHA on a store account page.

A returning customer knows her email, owns the phone in her hand, and still cannot get into her account, because the login wants her to retype a password she saved two years ago, then solve a picture puzzle, then transcribe a code that expires while she is switching apps. WCAG 2.2 Success Criterion 3.3.8, Accessible Authentication (Minimum), is aimed squarely at that stack of small humiliations.

The criterion does not ban passwords or verification. It bans making a cognitive function test, memorising, transcribing, or puzzle solving, the only way in. This post covers what counts as a test, which alternatives satisfy the rule, and why the paste-blocking scripts some stores still run are indefensible under it.

What 3.3.8 actually prohibits

At Level AA, a login step must not require a cognitive function test unless one of four things is true: an alternative authentication method exists that has no such test, a mechanism helps the user complete it, the test is object recognition, or it asks the user to identify non-text content they themselves provided to the site. Remembering a password is a test. Retyping a one-time code from another device is a test. A well-aimed picture CAPTCHA is a test.

The Level AAA version, 3.3.9, drops the object recognition and personal content allowances. Most consent decrees and procurement contracts still point at AA, so 3.3.8 is the working target, but teams designing a new account system today should know the stricter version exists.

Alternatives that satisfy the rule

Email magic links, passkeys and platform biometrics, password manager autofill, and copy-paste friendly code fields all remove the memory or transcription burden. The cheapest change on most stores is embarrassingly small: stop blocking paste in password and code fields. A user whose manager fills the field has not cheated; she has used the exact mechanism the criterion wants available.

For one-time codes, let the field accept the full code in one paste, use autocomplete='one-time-code' so phones offer the code from the message, and give the code a lifespan measured in minutes of real human switching between apps, not seconds.

CAPTCHA, honestly assessed

A CAPTCHA at login or checkout mostly taxes humans, including humans with cognitive and visual disabilities, while scripted abuse moved on to solver services and residential proxies years ago. If bot pressure forces a challenge, put it behind risk signals rather than in front of every returning customer, and keep a non-puzzle route open: a verified email link is an authentication method, not a loophole.

A short audit you can run today

Log out. Log back in with a password manager, with paste disabled in your test notes, and with your phone in another room for the code step. Time each stage and note every point where memory or transcription was the only route. Each such point is a 3.3.8 finding with a named fix, and most fixes are configuration, not redevelopment.

Related reading: Accessible Quantity Pickers and Steppers on Product Pages, Accessible Back in Stock Forms: The Email Field Is Only Half the Job, Accessible Address Autocomplete and Lookup Fields at Checkout.

Frequently asked questions

Are passwords banned by WCAG 2.2?

No. Passwords are allowed. What 3.3.8 prohibits is a login that can only be completed by memorising or transcribing something, with no alternative method and no mechanism such as password manager support to help. A passkey, magic link, or paste-friendly field alongside the password satisfies it.

Does blocking paste in a password field cause a failure?

It can. Preventing paste removes the mechanism many users rely on to complete authentication without memorising, which is the support the criterion expects. It also weakens security in practice, because users respond by choosing shorter passwords they can type.

Do one-time codes sent by text or email pass?

Only if the user is not forced to rely on memory or manual transcription alone. Supporting autocomplete='one-time-code', allowing paste, and offering an alternative such as a sign-in link keeps the flow inside the rule. A short expiry that forces rushed retyping works against it.

What about the picture puzzles at checkout?

Object recognition is one of the allowances at Level AA, but it is the weakest ground to stand on and disappears at AAA under 3.3.9. Risk-based triggering, where most customers never see a challenge, plus a non-puzzle alternative, is the defensible setup.