Quick gut check: if a user can't read warped, overlapping letters, or can't hold a mental math problem in their head long enough to type the answer, can they still create an account on your site? If the honest answer is "no, not without help," you've got a WCAG problem — and it's an easy one to fix once you know what the rule actually requires.
This isn't an edge case buried in fine print. It's a named, numbered success criterion in WCAG 2.2, and it's aimed directly at the classic squiggly-text CAPTCHA sitting on your signup form right now.
The Stat: WCAG 2.2 SC 3.3.8 Accessible Authentication (Minimum) (Level AA) says a cognitive function test — such as remembering a password or solving a puzzle — cannot be required for authentication unless an alternative method, an assistance mechanism, or an object-recognition exception is provided. (Source: W3C WCAG 2.2)
Why "it's just a CAPTCHA" isn't a defense anymore
CAPTCHAs exist to stop bots, and that's a legitimate goal — spam signups and credential-stuffing attacks are real problems. But the traditional implementation, distorted text you have to transcribe, or a logic puzzle you have to solve under a timer, is a cognitive function test. It asks every single user to prove they can perceive a specific visual pattern or hold a multi-step reasoning task in working memory, with no other way through.
That's precisely the pattern WCAG 2.2's Accessible Authentication (Minimum) criterion was written to close. It doesn't ban CAPTCHAs outright. It bans making one the only door into your form.
What SC 3.3.8 actually requires
The rule, in plain language: you cannot require a cognitive function test for authentication unless you also provide one of the following:
- An alternative authentication method that doesn't rely on the same cognitive test (for example, a passkey, a magic link sent by email, or a "call me" verification option).
- A mechanism to assist the user in completing the test (think: a "read the text aloud" audio option alongside the visual puzzle, or a password manager that's allowed to autofill without being blocked).
- The object-recognition exception — identifying objects in an image, such as "select all the images with a bicycle," is explicitly carved out as permitted, since it doesn't rely on the same memory or transcription burden as distorted text or arithmetic.
That last point matters, because it's the one people misread most often. It's not that image-based challenges are automatically fine and text-based ones are automatically broken — it's that WCAG specifically names object recognition as an accepted exception, while a logic puzzle or a "type what you see" text CAPTCHA, offered with no alternative, fails the criterion outright.
The checklist: does your CAPTCHA pass or fail?
| Your current setup | SC 3.3.8 status |
|---|---|
| Distorted-text CAPTCHA, no alternative offered | Fails |
| Math or logic puzzle, no alternative offered | Fails |
| Object-recognition challenge ("select the traffic lights") | Permitted exception |
| Puzzle CAPTCHA + an audio or "email me a link" fallback | Passes |
| Any CAPTCHA + a genuine alternative authentication path | Passes |
If your form only has one row from that table and it's one of the first two, that's the fix to prioritize this week.
How to actually fix it
- Audit every form on your site that gates access with a CAPTCHA — signup, login, password reset, contact forms.
- For any puzzle- or text-based CAPTCHA, add a second path: a magic link, an SMS or email code, or a "verify by phone" option.
- If you keep a visual challenge, add an audio alternative or a way to request human assistance.
- If you switch to an image-based challenge, confirm it's genuine object recognition (select the item shown) rather than a disguised logic or memory task.
- Re-check WCAG SC 1.1.1 while you're in there — CAPTCHA also needs a text alternative that identifies its purpose, per WCAG 1.1.1 Non-text Content, which explicitly lists CAPTCHA as needing alternative forms in different sensory output modes.
Worth noting: some CAPTCHA vendors are already ahead of this. hCaptcha's own accessibility page documents audio challenges and assistive-technology-compatible flows, which is a reasonable model for what "assistance mechanism" looks like in practice if you're not ready to rebuild your authentication flow from scratch.
What a compliant alternative actually looks like in practice
"Add an alternative method" is easy to write on a checklist and harder to picture concretely, so here's what teams are actually shipping to satisfy SC 3.3.8 without weakening bot protection:
- Magic links. Instead of typing a password (or solving a CAPTCHA to prove you're not a bot before you can type one), the user enters their email and clicks a one-time link. There's no puzzle to solve and no password to remember, and it's already how a huge share of SaaS products handle login.
- Passkeys / WebAuthn. A device-based credential (Face ID, Windows Hello, a hardware key) replaces both the password and the CAPTCHA in one step, since the authentication itself proves you're a real, present human without asking anyone to transcribe anything.
- SMS or email one-time codes. A six-digit code sent out-of-band is a cognitive-function test too, technically, but a much lighter one — and pairing it with autofill (most phones and password managers already fill OTP codes automatically) keeps the burden low for everyone, not just users with disabilities.
- A live "request help" path. For lower-traffic forms where building a second auth flow isn't realistic yet, even a visible support contact or chat option that a blocked user can reach counts as an assistance mechanism — it's a stopgap, not a long-term fix, but it keeps a real human from being locked out today while the real fix is in progress.
None of these require you to trust bot protection less. Passkeys and magic links are, if anything, harder for bots to automate than a CAPTCHA is — which is part of why so many teams are moving that direction anyway, accessibility aside.
Testing it yourself before you ship
Once you've added an alternative path, actually try it the way an affected user would: turn on a screen reader, tab to your CAPTCHA-gated form, and see whether your new alternative is announced and reachable before the puzzle blocks you, not buried in a footer link three scrolls away. If the only way to discover the accessible option is to already have solved the CAPTCHA once, you haven't actually fixed anything — you've just hidden the same wall behind a different door.
The part teams miss
None of this requires ripping out your bot protection. It requires making sure the bot protection isn't also filtering out legitimate users who can't solve a puzzle under time pressure or can't perceive distorted glyphs. A second path, an audio option, or a switch to genuine object recognition is a small change relative to the exposure of leaving a hard gate in place.
If you're not sure whether your current forms would pass or fail SC 3.3.8, that's exactly the kind of thing worth checking before a user — or a plaintiff's attorney — finds out for you. A free scan that flags authentication barriers on your forms is a fast way to see where you stand.