CAPTCHA Accessibility: Which Bot Checks Lock Out Disabled Users, and What to Use Instead

Bot protection is usually chosen by a security or growth team, configured once, and forgotten. Then a blind customer can't submit a contact form, a user with a tremor can't finish a slider puzzle at checkout, and someone using a VPN for privacy gets an endless loop of "select all the traffic lights".

CAPTCHAs are designed to be unreadable by machines. Screen readers and other assistive technologies are machines. That tension has been documented by the W3C for nearly two decades, and it hasn't gone away. (W3C, Inaccessibility of CAPTCHA)

This guide covers which kinds of CAPTCHA exclude whom, what WCAG and the European Accessibility Act require, how the current approaches compare, and how to choose bot protection that protects your forms without locking customers out.

Who each type of CAPTCHA excludes

Not all CAPTCHAs fail the same people. The table below is the starting point for any decision.

Type	How it works	Who it excludes or burdens
Distorted text	Read and type warped characters	Blind and low-vision users; many dyslexic users; anyone with cognitive or memory impairments
Image grids	"Select all squares with bicycles"	Blind and low-vision users; users with cognitive impairments; anyone who finds the task ambiguous
Audio challenge	Listen to and type distorted spoken digits or words	Deaf and hard-of-hearing users; deafblind users; anyone in a noisy setting; non-native speakers
Slider or puzzle	Drag a piece into place	Keyboard-only users; switch and voice-control users; people with motor impairments
Logic or maths questions	"What is 3 + 4?"	Users with dyscalculia or cognitive impairments; still trivial for bots
Checkbox plus behavioural scoring	Tick "I'm not a robot"; risk is scored from behaviour	Users whose interaction looks "unusual" (keyboard, switch, voice, screen reader) may be escalated to a harder challenge
Invisible risk scoring	Scored silently from signals; challenge only if suspicious	Users on VPNs, corporate proxies or shared networks, and assistive tech users, can be misflagged
Proof-of-work	The browser solves a computational puzzle in the background	Mostly invisible; can be slow on older or low-powered devices
Token-based attestation	Cryptographic tokens (for example Privacy Pass) vouch for a prior verification	Minimal interaction; depends on browser and platform support

Two patterns stand out. First, every interactive challenge excludes some group, because each one relies on a particular sense or ability. Second, the invisible approaches move the problem rather than removing it: whoever gets misclassified gets pushed back to an interactive challenge, and assistive technology users are disproportionately likely to be misclassified.

What WCAG requires

There's no blanket ban on CAPTCHA in WCAG, but several success criteria apply.

SC 1.1.1 Non-text Content (Level A) has a specific CAPTCHA provision. If the purpose of non-text content is to confirm that a person rather than a computer is present, you must:

• provide a text alternative that identifies and describes the purpose of the CAPTCHA, and
• provide alternative forms of CAPTCHA using output modes for different types of sensory perception.

In practice, that means an image-only CAPTCHA fails. An image challenge with an audio alternative is the minimum, and as the table shows, that still leaves out deafblind users.

SC 3.3.8 Accessible Authentication (Minimum) (Level AA, WCAG 2.2) applies when the CAPTCHA sits in a login or authentication step. It prohibits cognitive function tests unless an alternative method, a mechanism to help, or an exception applies. Notably, at Level AA object recognition (such as "select the bicycles") is an allowed exception; at AAA (SC 3.3.9) it isn't. Text transcription and puzzle-solving are not exempt. We've covered this in depth in WCAG 2.2 SC 3.3.8 Accessible Authentication.

Other criteria regularly catch CAPTCHA implementations out:

• SC 2.1.1 Keyboard and SC 2.5.7 Dragging Movements (AA, WCAG 2.2): slider and drag-to-fit puzzles need a single-pointer or keyboard alternative.
• SC 2.2.1 Timing Adjustable: challenges that expire quickly need a way to extend or retry without losing the form.
• SC 4.1.2 Name, Role, Value: the widget itself, often inside an iframe, must expose meaningful names and states to assistive technology.
• SC 3.3.1 Error Identification: "verification failed" with no explanation or next step is an error-handling failure, not just a UX one.

Why this is an EAA issue, not just a UX one

The European Accessibility Act has applied since 28 June 2025 to in-scope consumer services, including e-commerce, consumer banking, passenger transport booking, e-books and electronic communications. The technical benchmark used in practice is EN 301 549, which incorporates WCAG 2.1 AA for web content.

Bot checks almost always sit at the points that matter most in those services: account creation, login, password reset, contact and complaint forms, and checkout. If a disabled customer can't get past the challenge, they can't use the service. It doesn't help that the CAPTCHA is a third-party widget: under the EAA, the obligation sits with the service provider. The same logic applies as with consent banners and other third-party components.

Enforcement in 2026 has mostly taken the form of market surveillance inspections, formal information requests and, in Germany, competitor warning letters. Forms that block users outright are exactly the kind of barrier that shows up in complaints.

How the main approaches compare in 2026

Here is how the common options look from an accessibility perspective, based on published documentation and independent commentary. Treat vendor claims, including competitors' claims about each other, with caution, and test with your own users.

Classic image and audio CAPTCHAs. The W3C groups these as "legacy approaches" with significant accessibility and security limitations. Modern AI models solve many of them more reliably than people do, so the accessibility cost buys less and less security. (W3C editor's draft)

Google reCAPTCHA. v2 offers an audio fallback, but users and practitioners consistently report it as difficult in practice. v3 is score-based and invisible, but if a site escalates low scores to a v2 challenge, users whose behaviour looks atypical can end up back at the image grid. (Friendly Captcha, vendor source)

Cloudflare Turnstile. Turnstile is designed to avoid visual puzzles for most users. Cloudflare redesigned it in 2026 and states that it meets WCAG 2.2 AAA; at the time of writing that claim is self-declared, without a published third-party audit. Network-reputation signals can also flag users on VPNs, corporate proxies or shared connections. (Friendly Captcha, competitor source)

Proof-of-work CAPTCHAs. These run a computational puzzle in the browser and need no interaction from the user in most cases, which removes the sensory and cognitive barriers. Check performance on low-end devices and what happens when JavaScript fails or is slow.

Token-based approaches. The W3C note discusses Privacy Pass and similar "Turing token" approaches as state-of-the-art options that verify humanity with cryptographically blinded tokens, reducing how often anyone sees a challenge at all.

For a readable overview of how CAPTCHAs and other authentication methods affect disabled users, Smashing Magazine's 2025 piece is a good companion read. (Smashing Magazine)

A decision framework for accessible bot protection

Start from the threat, not the widget.

1. Ask whether you need a user-facing challenge at all

Many forms can be protected without asking users to prove anything:

• Rate limiting per IP, account or device
• Honeypot fields: hidden inputs that bots fill in and humans don't (hide them properly with CSS and aria-hidden, and make sure they can't be reached by keyboard)
• Time-to-submit checks: reject submissions completed implausibly fast
• Server-side validation and content filtering for spam
• Email or SMS confirmation after submission rather than a gate before it

For low-value targets such as newsletter sign-up or contact forms, these are often enough on their own.

2. If you need more, prefer invisible and non-interactive checks

Risk scoring, proof-of-work and token-based attestation keep most users from ever seeing a challenge. That's the right default.

3. Never make a hard challenge the only path

Whatever you choose, someone will be misclassified. Decide in advance what happens to them:

• Offer a second, different modality if a challenge is shown, as SC 1.1.1 requires.
• Provide a human route: a phone number, email address or chat that can complete the same task, clearly signposted next to the challenge.
• Make sure failure preserves the form data and explains what to do next.
• Avoid escalation loops where failing one challenge produces another.

4. Treat authentication separately

At login, passkeys, passwordless email links and password-manager-friendly fields reduce both bot risk and cognitive load. Combine them with server-side risk controls rather than a puzzle. See our accessible forms guide for field-level patterns.

5. Test with real assistive technology

Automated scanners rarely see inside CAPTCHA iframes, and they can't tell you whether a challenge is solvable. Test the full form with:

• keyboard only (including any slider or drag interaction)
• a screen reader (NVDA with Firefox or Chrome, VoiceOver with Safari)
• voice control (Voice Control on macOS or iOS, or Dragon)
• a VPN switched on, to see what misclassified users experience
• 200% and 400% zoom

A quick checklist

• Every form with a CAPTCHA has been reviewed: is a user-facing challenge necessary?
• Server-side protections (rate limits, honeypots, timing) are in place first
• Any visible challenge has a text alternative and a second sensory modality
• No drag-only or time-limited challenge without an alternative
• Login steps meet SC 3.3.8 (no transcription or puzzle tests without an alternative)
• A human contact route is visible next to the challenge
• Failure keeps the user's data and explains the next step
• Tested with keyboard, screen reader, voice control and a VPN
• The vendor has been asked for an Accessibility Conformance Report

The bottom line

The question isn't "which CAPTCHA is accessible?" Every interactive challenge excludes someone. The better question is: how few people need to see a challenge at all, and what happens to the ones who do? Push protection server-side, keep challenges invisible by default, and always leave a second door open. That keeps bots out of your forms without keeping disabled customers out of your service.

This article is general information, not legal advice.