Most CAPTCHAs, as actually deployed, are not ADA compliant in any practical sense. The ADA itself never mentions CAPTCHAs — but courts and the Department of Justice consistently point to WCAG 2.1 AA as the measure of an accessible website, and a visual puzzle with a broken or missing alternative fails it. The good news: you can keep bots out without one. Below, a neutral ranking of the four realistic options — honeypots, Cloudflare Turnstile, reCAPTCHA v3, and reCAPTCHA v2/hCaptcha — from a company that sells none of them.
One thing worth knowing about this topic: almost everything ranking for “accessible CAPTCHA” is published by a CAPTCHA vendor grading its own homework. We do manual accessibility remediation, not bot protection, so we have no product in this race.
Why CAPTCHA is the top screen reader complaint on the web
CAPTCHA is not a minor annoyance for disabled users — it is their single biggest barrier, measured repeatedly. In WebAIM’s Screen Reader User Survey #10, run in late 2023 and early 2024, respondents ranked CAPTCHA the most problematic item on the web “by a notable margin” — a spot it has held across more than a decade of these surveys.
The W3C studied the problem formally. Its note Inaccessibility of CAPTCHA, last published as a Group Draft Note in December 2021, puts it plainly: “a CAPTCHA not only separates computers from humans, but also often prevents people with disabilities from performing the requested procedure.” A test designed to prove you’re human keeps failing to recognize disabled humans.
The audio fallback doesn’t rescue it. In a University of Washington study by Bigham and Cavender presented at CHI 2009, 89 blind web users solving ten popular audio CAPTCHAs succeeded only 43% of the time. Screen readers talk over the playing audio, and one failed attempt means starting over with a new puzzle. Research since then, including the W3C note, has not found that picture meaningfully improved.
What WCAG actually requires from a CAPTCHA
WCAG doesn’t ban CAPTCHAs — it sets conditions that most implementations fail. Success Criterion 1.1.1 Non-text Content carries a specific CAPTCHA exception: per the W3C’s Understanding document, you must provide “text alternatives that identify and describe the purpose” of the CAPTCHA, and “alternative forms of CAPTCHA using output modes for different types of sensory perception.” A visual puzzle alone, with no working audio or logic alternative, fails at Level A — the lowest bar.
WCAG 2.2 tightened things further for logins. New Level AA criterion 3.3.8 Accessible Authentication (Minimum) says a “cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process” unless an alternative exists — and the W3C explicitly counts transcribing characters and solving puzzles as cognitive function tests. If a CAPTCHA guards your login, that criterion applies directly. We cover the new criteria in what’s new in WCAG 2.2.
On the legal side, remember what a plaintiff’s tester documents: a screen reader user reaching your form and being unable to submit it. The CAPTCHA doesn’t have to be named in a statute to end up quoted in a demand letter — it just has to be the reason a form couldn’t be completed. The playbook in how to avoid an ADA lawsuit starts with exactly these show-stopper barriers.
How the four options stack up
Here is the honest comparison, ranked by what a real assistive-technology user experiences — not by vendor marketing.
| Rank | Option | What most visitors see | What a screen reader user hits | Accessibility verdict |
|---|---|---|---|---|
| 1 | Honeypot + server-side checks | Nothing | Nothing, if built correctly | Best: no test for any human to fail |
| 2 | Cloudflare Turnstile | Nothing, or a brief checkbox | Same as everyone; docs state WCAG 2.2 AA compliance | Strong: no visual puzzles by design |
| 3 | reCAPTCHA v3 | Nothing (invisible score) | Depends entirely on what YOU do with low scores | Conditional: accessible only if your fallback is |
| 4 | reCAPTCHA v2 / hCaptcha | Checkbox, then image grids | Image puzzles, weak audio fallback, or a separate signup flow | Weakest: the classic barrier, still live |
| — | Verdict | Use a honeypot for basic forms; Turnstile when you need a hosted widget. Replace v2 and default hCaptcha. |
1. Honeypots: the most accessible option for most forms
The most accessible CAPTCHA is no CAPTCHA — a trap only bots fall into. A honeypot is a form field hidden from human visitors; spam bots auto-fill every field, so a filled honeypot flags the submission. The W3C’s CAPTCHA note lists honeypots among its recommended stand-alone alternatives and notes the approach is easy to implement, with built-in support in common content management systems.
One build detail matters for accessibility: hide the field the right way. A field pushed off-screen with CSS is still announced by screen readers and reachable by keyboard. Set aria-hidden="true" and tabindex="-1" on it, and give it a label such as “Leave this field empty” as a safety net. Pair the honeypot with a time-to-submit check and rate limiting, and you’ve covered the spam that hits typical small-business contact forms — with zero burden on any human. Our accessible forms guide covers the rest of the form around it.
2. Cloudflare Turnstile: the best drop-in widget
If you want a hosted widget with a dashboard, Turnstile is the strongest accessibility pick. Per Cloudflare’s documentation, Turnstile verifies visitors with non-interactive browser challenges and is designed to “avoid showing a visual or interactive puzzle to a user” — and the docs state plainly that “Turnstile is WCAG 2.2 AA compliant.” In its managed mode, some visitors see a simple checkbox; no one gets an image grid.
It also removes the price excuse: Cloudflare’s plans page lists a free tier with up to 20 widgets per account, which covers most small-business sites many times over. It works on any site — you don’t need to host with Cloudflare. The trade-off is trusting a third party’s scoring, and treating any vendor’s compliance claim as a starting point to verify, not a guarantee.
3. reCAPTCHA v3: invisible, but only as accessible as your fallback
reCAPTCHA v3 shows users nothing — which sounds ideal until you ask what happens to the people it distrusts. Per Google’s developer documentation, v3 “returns a score for each request without user friction” — 1.0 likely human, 0.0 likely bot — and “will never interrupt your users.” The accessibility question moves entirely to your side: what does your site do when the score comes back low?
Google recommends handling low scores behind the scenes — requiring email verification, or routing risky submissions to moderation. Do that, and v3 is genuinely accessible. But many sites instead bounce low scorers to a v2 image challenge, and the W3C note observes that these secondary challenges are exactly where the barriers return. The W3C also flags the privacy cost of reCAPTCHA’s data collection. Ranked third: excellent when implemented thoughtfully, and rarely implemented thoughtfully.
4. reCAPTCHA v2 and hCaptcha: the ones to replace
These are the fire-hydrant-and-crosswalk puzzles, and they rank last. To be fair to Google: its reCAPTCHA accessibility page says the widget “works with major screen readers such as ChromeVox, JAWS, NVDA and VoiceOver” and announces status changes. The checkbox itself is usually operable. The failure mode is what comes after — image grids when the system doubts you, with an audio alternative from the same family of tests that blind users in the UW research solved less than half the time. The same doc warns that verification expires after a period, so slower users can complete the puzzle and still lose it.
hCaptcha, the common drop-in replacement, is visual-first by design. Its official accessibility page acknowledges “some features like visual challenges cannot be fully accessible while fulfilling security functions,” and its accommodation is a separate flow: disabled users sign up for an accessibility account and receive “an encrypted cookie that can be used several times per day, but must be refreshed periodically via login.” Read that as a customer: a blind visitor must register with a third-party vendor before they can submit your contact form. That’s a side door, not an entrance — and it only helps users who already know the program exists.
How to switch without opening the spam floodgates
Replacing a CAPTCHA is usually an afternoon of work. Here’s the order we’d do it in:
- Inventory every form that has a CAPTCHA — contact, quote, newsletter, login, checkout. Checkout matters most; see what blind customers face in a screen reader checkout.
- Add a honeypot field and a time-to-submit check to each form, hidden with
aria-hidden="true"andtabindex="-1". - Add rate limiting and server-side spam filtering so a burst of submissions from one source gets throttled regardless of what the bot solved.
- Remove the visual CAPTCHA. If spam volume genuinely demands a widget, install Turnstile rather than an image-grid product.
- Test the finished form with a keyboard and a screen reader — every field reachable, every error announced, per WCAG 3.3.1 Error Identification.
- Recheck after any platform or plugin update, since form plugins love to reintroduce CAPTCHAs on update.
The CAPTCHA is rarely the only barrier on a form — unlabeled fields, silent error messages, and focus problems usually travel with it. That’s why we test forms with real assistive technology in a manual accessibility audit instead of trusting a scanner to guess. If you’d like a quick, free read on what your forms look like to the tools disabled visitors actually use, start with a free accessibility scan.