WCAG 2.2 Accessible Authentication: Can You Still Use CAPTCHA?

## The short answer

WCAG 2.2 success criterion **3.3.8 Accessible Authentication (Minimum)** says that no step in a login process may require a **cognitive function test** - such as remembering a password, solving a puzzle, or transcribing characters - unless you provide an alternative that does not, or a mechanism to assist. So you can keep passwords and even traditional CAPTCHAs, but only if users can rely on password managers (you must not block paste or autofill) and you offer a non-puzzle alternative. The cleanest way to comply is to support passkeys, email links, or OAuth, and never break copy-and-paste. This is an AA criterion; the AAA version, 3.3.9, is stricter.

## What counts as a cognitive function test

The criterion targets anything that taxes memory, problem-solving, or perception during authentication, including:

- Remembering and typing a password or PIN from memory.

- Solving a logic, maths, or word puzzle.

- Identifying objects in distorted images (classic image CAPTCHA).

- Transcribing characters from a distorted image.

- Recalling which images you chose at signup.

These are barriers for people with cognitive disabilities, memory impairments, dyslexia, and many older users - and they create friction for everyone.

## So are passwords banned?

No. Passwords are allowed because the criterion provides an exception for cognitive tests where a **mechanism is available to assist** the user. A password manager is exactly that mechanism. The practical requirement is therefore that your login form must:

- Allow pasting into the password field.

- Allow browser and third-party password managers to autofill.

- Use correct input types and autocomplete attributes so managers recognise the fields.

If your form disables paste "for security", you have turned an allowed password field into a memory test and failed the criterion. Disabling paste does not improve security; it pushes people towards weaker, memorable passwords.

## What about CAPTCHA?

CAPTCHA is the trickier case. A traditional puzzle or distorted-text CAPTCHA is a cognitive function test. To comply you must offer an **alternative authentication method that does not rely on a cognitive test**, or recognition of common objects (recognising a photo of a dog is explicitly allowed as an exception, because object recognition is not treated as a cognitive function test in the same way). In practice the safest route is to:

- Replace puzzle CAPTCHAs with risk-based or invisible bot detection that requires no user puzzle in the common case.

- If a challenge is shown, ensure object-recognition rather than transcription or logic puzzles.

- Always provide a non-CAPTCHA path such as an emailed link.

## The strongest compliance: passwordless

The most robust way to satisfy both 3.3.8 and the enhanced 3.3.9 is to remove the memory test entirely:

- **Passkeys / WebAuthn**: authentication via device biometrics or a security key. Nothing to remember, nothing to transcribe.

- **Email or SMS magic links**: the user clicks a link rather than recalling a secret. Ensure the code can be copied, not retyped from memory.

- **OAuth / single sign-on**: delegate to an identity provider the user is already signed into.

One caution: a one-time code that the user must read from one device and type into another can become a transcription test if you block paste. Allow autofill of one-time codes (using the appropriate autocomplete value) so the browser can insert them automatically.

## Common failure patterns

- Password fields with paste disabled via JavaScript.

- Missing or wrong autocomplete attributes, so password managers cannot fill the form.

- Custom inputs that break native autofill.

- Puzzle or distorted-text CAPTCHA with no alternative.

- Two-factor codes that must be retyped and cannot be pasted or autofilled.

- Security questions relying on recall as the only factor.

## How we approach it

When building enterprise-grade products at neart.ai, we treat authentication as a place where accessibility and security reinforce each other. Supporting passkeys and password-manager autofill reduces phishing risk and reduces the memory burden simultaneously - the accessible path and the secure path are the same path. The anti-pattern to retire is the well-meaning "disable paste" reflex.

## Testing checklist

- Paste a value into every credential and one-time-code field - does it accept it?

- Save the login in a password manager and confirm it autofills on return.

- Inspect form fields for correct autocomplete attributes.

- If a CAPTCHA appears, confirm a non-puzzle alternative exists.

- Attempt the full login using only autofill, no typing from memory.

## Practical takeaway

Don't ban passwords - just make sure paste and autofill work and a password manager can do the remembering. Replace puzzle CAPTCHAs with invisible detection plus an email-link fallback, and adopt passkeys where you can. If every step of login can be completed without recalling or transcribing a secret, you satisfy WCAG 2.2 accessible authentication comfortably.