Accessible authentication requires cognitive function test

What is this issue?

An authentication process (a login form, a password reset flow, a two-factor challenge, a session re-authentication prompt) offers no way to sign in without passing a cognitive function test. WCAG defines a cognitive function test as a task requiring the user to memorize information (a password), transcribe information (typing distorted CAPTCHA characters), perform a calculation, or solve a puzzle, and 3.3.8 requires that at least one authentication method avoid all four.

Two narrow exceptions exist: an object-recognition test (identify which images show a specific item) and a personal-content-recognition test (identify your own submitted photo) don’t count as violations, since they test a different, non-memory-based skill. Everything else, such as a password-only login with no alternative or a puzzle CAPTCHA gating the only sign-in path, fails.

Why does this matter?

For someone with a memory-related cognitive disability, a password-only login isn’t a minor friction point; it’s a wall. If they can’t reliably recall a password and the site also blocks paste (preventing a password manager from filling it in), there’s no path through the login screen at all, regardless of how motivated they are to use the service.

The same is true of a mandatory puzzle CAPTCHA for someone with dyscalculia who struggles with the arithmetic variant, or distorted-text CAPTCHAs for someone with dyslexia who can’t reliably transcribe warped characters. Where most accessibility failures degrade an experience, a cognitive-function-test-only authentication flow removes access to the account entirely: there’s no workaround available to the user, only to the site.

Who is affected?

• Cognitive disabilities: users with memory, attention, or processing differences may not reliably recall passwords, complete timed puzzle CAPTCHAs, or perform the arithmetic some CAPTCHA variants require, with no fallback if that’s the only path offered.
• Low vision users: distorted-text CAPTCHAs are, by design, hard to parse visually even with correction, and many implementations offer no equivalent audio or alternative challenge.
• Motor impairments: drag-slider and “trace the shape” CAPTCHA variants require precise, sustained pointer control that a switch device, head pointer, or limited fine motor control can’t reliably produce.

What users experience

Marcus has a traumatic brain injury that affects his short-term memory, so he relies entirely on his password manager to log into every account he uses. He tries to sign into a healthcare portal to check a test result, but the password field has paste disabled, a “security” measure the team added without realizing it blocks password manager autofill. Marcus can’t recall the 20-character random password his manager normally supplies, has no other way to authenticate, and gives up checking his results online, calling the office’s phone line instead.

How do I fix it?

Offer at least one authentication method that doesn’t require a cognitive function test, alongside whatever primary method you already use. This satisfies 3.3.8 directly, because the criterion doesn’t ban passwords or CAPTCHAs outright; it requires that a cognitive-test-free path exist somewhere in the flow, so a user who can’t complete the test isn’t locked out.

The most broadly compatible options are a passkey (device-based biometric or PIN authentication via WebAuthn, which replaces password recall with something the device already handles) or an emailed magic link (the user proves identity by clicking a link sent to an inbox they’re already signed into, with no password to remember). SMS or authenticator-app one-time codes and OAuth/social sign-in also qualify, since none of them require memorizing, transcribing, calculating, or puzzle-solving.

If you keep a password field as the primary method, allow paste into it. Blocking paste prevents password managers from autofilling and forces manual recall, reintroducing the exact cognitive function test this criterion exists to route around.

Code Examples

<!-- CAPTCHA puzzle is the only way to reach the login button -->
<form>
  <label for="username">Username</label>
  <input type="text" id="username">
  <label for="password">Password</label>
  <input type="password" id="password" onpaste="return false">
  <div class="captcha-puzzle">Drag the slider to complete the puzzle</div>
  <button type="submit">Log in</button>
</form>

<!-- Password field allows paste (password manager autofill works) -->
<form>
  <label for="username">Username</label>
  <input type="text" id="username">
  <label for="password">Password</label>
  <input type="password" id="password">
  <button type="submit">Log in</button>
</form>

<!-- Cognitive-test-free alternative offered alongside it -->
<button type="button" id="passkey-login">Sign in with a passkey</button>
<a href="/login/magic-link">Email me a sign-in link instead</a>

The fix has two parts working together: removing onpaste="return false" restores password manager autofill on the existing field, and the passkey/magic-link buttons give users a complete alternative that never asks them to remember or transcribe anything at all. Either change alone helps; offering both gives the widest coverage.

Common Mistakes

Mistake: “Any CAPTCHA violates this criterion, so we need to remove ours entirely.” WCAG carves out two specific exceptions, object recognition (“select the images with a crosswalk”) and personal content recognition, because they test a different skill than memory or transcription. A CAPTCHA using only those patterns, with no distorted-text or puzzle fallback, can be compliant as-is.

Mistake: “Blocking paste in the password field is a security best practice, so it’s fine.” Blocking paste is specifically what breaks password manager autofill, forcing the user back into manually recalling and typing their password: the exact cognitive function test 3.3.8 exists to route around. Security guidance from major browser vendors and OWASP has moved away from this pattern for this reason; allowing paste is one of WCAG’s own listed ways to comply.

Mistake: “We have a ‘forgot password’ link, so we’re covered.” A password reset flow that falls back to security questions (“What street did you grow up on?”) is still a memorization-based cognitive function test, just a different one from the main password field. The alternative method has to avoid cognitive function tests altogether, not just relocate one.

Mistake: “This only applies to the initial login screen.” 3.3.8 applies to any point in a process where the user re-proves their identity, such as a 2FA challenge, a session timeout re-authentication prompt, or a step-up verification before a sensitive action, not only the first sign-in a user ever completes.

How RedFlag Detects This

Guidance only: RedFlag documents this issue but does not currently flag it; verify manually. Judging whether a specific authentication flow requires a cognitive function test, whether an alternative path genuinely avoids one, and whether an object-recognition or personal-content exception applies all require evaluating live authentication UX and business logic that a static page scan cannot observe. RedFlag’s own coverage model records this criterion’s evidence as docs_only, confirming there is no automated detector for it today.

False negative: every occurrence is a false negative in the sense that nothing is ever automatically flagged, so a login page that requires a puzzle CAPTCHA with no alternative will pass every automated RedFlag scan silently. False positive: not applicable, since this check never raises an automated violation to begin with. Manual step: walk every authentication entry point on the site (initial login, password reset, 2FA, session re-authentication) and confirm at least one path never asks the user to memorize, transcribe, calculate, or solve a puzzle.

Manual Testing

1. List every point in the product where a user has to authenticate: initial login, password reset, 2FA/step-up verification, and session timeout re-authentication.
2. For each one, walk through it and note whether it requires memorizing something (a password with no autofill support), transcribing something (a CAPTCHA), calculating something, or solving a puzzle.
3. Confirm at least one full path from start to finish avoids all four, without switching to a different, still-cognitive-test-based fallback partway through (like security questions on password reset).
4. If a CAPTCHA is present anywhere in the flow, confirm it uses only object-recognition or personal-content-recognition challenges, or that an equivalent non-CAPTCHA path exists alongside it.
5. Try pasting a password from a password manager into every password field in the flow; if paste is blocked anywhere, that field fails.

Related WCAG Success Criteria

3.3.8 Accessible Authentication (Minimum): At least one authentication method must be available that doesn’t rely on a cognitive function test, except for object-recognition and personal-content-recognition tests. This rule is a direct check of whether that alternative path actually exists in the product.

A stricter Level AAA sibling, 3.3.9 Accessible Authentication (Enhanced), removes even the object-recognition and personal-content exceptions, useful context if the product targets AAA conformance, though it’s out of scope for the AA baseline this rule documents.

Related Issues

Session times out without warning shares the same new-in-2.2 concern with not creating unnecessary re-authentication burden: a session timeout that forces a user back through this exact cognitive-test-gated login flow compounds both problems at once.

Form error is not clearly identified matters directly on a login form: a failed authentication attempt needs a clear, specific error, or a user already struggling with the authentication method has no idea what to correct.

User must re-enter information already provided in the same process covers the same “don’t add unnecessary friction to completing a process” principle 3.3.8 is part of, applied to multi-step forms instead of login.

Navigation order is inconsistent across pages and Help mechanism location is inconsistent across pages are the other WCAG 2.2 additions most likely to appear alongside this one in the same audit, since all three are new criteria focused on reducing cognitive load during a task.

References

• W3C Understanding 3.3.8: Accessible Authentication (Minimum)
• W3C WCAG 2.2: What’s New
• MDN: Web Authentication API