hCaptcha's "Accessibility" Mode Is a Fucking Cookie
And it's wrapped in a maze of broken promises, bad design, and outright user hostility
You've probably heard of hCaptcha — the CAPTCHA alternative that brags about privacy, security, and accessibility. You may have even used it. You may have trusted it.
If you did, I don’t blame you. Its marketing is slick. Its messaging is persuasive. It claims to solve everything reCAPTCHA gets wrong.
But if you’re blind, visually impaired, or use assistive tech, you already know the truth:
hCaptcha is a lie.
Its so-called “accessibility” feature is not a feature. It’s a half-baked, non-functional nightmare duct-taped together with a browser cookie and a prayer.
And even if you somehow get that cookie? It still doesn’t guarantee a damn thing.
Let’s Get This Straight: There Are Two “Accessibility” Features — and Both Are a Disaster
hCaptcha touts two things as part of its accessibility support. Both are hostile, fragile, and completely unreliable in practice.
1. The Cookie — The "Bypass" You Can't Actually Reach
This cookie is supposed to let you bypass hCaptcha challenges entirely. You check the “I am human” box, and it quietly lets you through. No image grid, no text challenge, no puzzles. That’s the intended behavior — and it’s actually the right idea in theory.
But in practice? It's a complete disaster.
Here’s how it works (or is supposed to):
- You go to the hCaptcha accessibility request page.
- You enter your email address.
- You are shown a one-time code.
- You are told to send that code via SMS to a U.S.-based phone number.
- You click “Confirm Code.”
And then?
"An error has occurred."
No confirmation.
No fallback.
No cookie.
No support.
I don’t even know what was supposed to happen next — because the process never worked. The phone number never replied. No verification message came back. Clicking "Confirm Code" just dropped me into a silent error state.
I followed the instructions exactly. It still failed.
This isn't a one-off bug. It’s repeatable. It’s systemic. It’s broken.
And even if it worked?
- It depends on a third-party cross-site cookie (which is blocked by most modern browsers).
- It expires after a short period, forcing you to redo this entire idiotic ritual again and again.
- It offers no transparency about expiration time, current status, or whether it’s even functioning correctly.
- You’re forced to compromise your privacy and use a working U.S.-capable phone number, just to prove you're human.
All of this to maybe, possibly, skip a CAPTCHA if the moon is aligned and the backend isn't silently broken that day.
This is not accessibility. This is ritual humiliation.
2. The Text-Based Challenge — If You're Lucky
Then there's the other so-called feature: the text-based CAPTCHA.
This is the one most people think of when they imagine accessible verification:
- “What is 5 + 2?”
- “What’s the first letter of the word ‘tree’?”
Plain language. Easy to understand. Solvable with screen readers. This could actually work.
But here’s the catch:
- This challenge does not require the cookie.
- It’s only available if the website you’re visiting has explicitly enabled it in their hCaptcha configuration.
If they didn’t?
You’re back to blurry fire hydrants and broken UI grids — even if you’re using a screen reader. Even if you’ve enabled accessibility settings. Even if you cannot see.
hCaptcha doesn’t detect that.
It doesn’t care.
Accessibility is opt-in for the site.
And if they didn’t check the right box in their dashboard? You're screwed.
So we’re left with two broken paths:
- The cookie, which requires you to complete a multi-step process that is currently non-functional and ends in a silent, unsupported failure.
- The text challenge, which you don’t control and which most websites haven’t even enabled.
This isn’t accessibility. This is gatekeeping with extra steps.
What’s at Stake
When hCaptcha fails — and it will — people with disabilities cannot:
- Log in to accounts
- Submit forms
- Sign up for services
- Reach support
- Leave comments
- Use your site at all
This isn’t about convenience.
It’s about being excluded from society because a CAPTCHA widget decided that human beings should pass a surveillance-grade verification just to get basic access.
What You Can Use Instead: Real Alternatives to HellCaptcha
Look — nobody wants spam.
Nobody wants a flood of bots hammering their forms.
But there are ways to stop bots that don’t actively screw over disabled users or require sacrificing privacy.
Here are alternatives to hCaptcha that actually work — and that don’t treat accessibility like a side quest:
🛡️ Cloudflare Turnstile
Drop-in replacement for hCaptcha or reCAPTCHA.
- Privacy-first — no tracking, no fingerprinting.
- Accessible by default — doesn't even show a challenge most of the time.
- Can be configured to never show a visual CAPTCHA.
- No cookies, no SMS bullshit, no image grid.
Cloudflare already knows how to detect bots using behavior, headers, and passive signals.
Let them handle it. It Just Works™ — and it doesn’t make blind people suffer to log in.
Use this if: You want an easy, free, privacy-respecting CAPTCHA that actually respects your users.
🐜 Honeypots
An old-school trick, still effective.
You insert a hidden form field that bots will fill out, but humans never see.
- Invisible to users.
- Easy to implement.
- Zero interaction required.
You can combine this with a delay timer (e.g. "only submit if this form took >3 seconds to fill out") for even more spam resistance.
Use this if: You want a no-JS, zero-friction, fully accessible solution.
🧠 Behavioral Analysis
Instead of asking users to prove they’re human, you can observe:
- Typing speed
- Mouse movement
- Timing between events
- IP and header patterns
These methods don’t block access. They just score requests, letting you escalate challenges only if necessary.
Use this if: You’re running a larger site and want something seamless and smart without front-end friction.
🧪 Progressive Challenge Escalation
Start with nothing.
Only show a challenge if something looks suspicious (e.g. brute force attempts, bad IP ranges, rapid-fire requests).
- Keeps things open for most users.
- Saves your bandwidth.
- Doesn’t hurt real people until a bot actually misbehaves.
Use this if: You want to avoid punishing your legitimate users.
🚫 Nothing
In many cases?
You don’t need a CAPTCHA at all.
You’re not Google. You’re not running a global login gateway.
If you’re just protecting a blog comment form or a contact page?
- A CSRF token
- A unique form action
- A backend rate limit
- And a required hidden field
...will probably stop 99.9% of bots.
Use this if: You’re not at massive scale and just want basic protection.
The Bottom Line on Alternatives
If you’re using hCaptcha today, you’re not alone — and it’s not your fault.
The marketing looks solid. The documentation promises accessibility. It’s pitched as a drop-in, privacy-friendly upgrade to reCAPTCHA. You were told this was the responsible choice.
But in practice, hCaptcha is locking real people out. Blind users. Screen reader users. People just trying to sign in, submit a form, or use your site.
And now you know.
The good news is: you have better options — right now.
There are solutions that don’t rely on broken SMS flows, fragile cookies, or inaccessible image puzzles. You don’t need to sacrifice accessibility to fight bots.
So if you’ve already implemented hCaptcha, this isn’t a callout — it’s an invitation:
Swap it out. Try something better.
You care about users — or you wouldn’t be reading this.
Let’s build a web that works for everyone.
You should also check out this open source proof of work solution. It does support inaccessible image codes, but not by default, and only as a paid feature: https://github.com/altcha-org/altcha
At least in graphical browsers there are sometimes audio challenges. You can either listen or download an mp3 of words or symbols. Problems are since many of us are useing console non-javascript browsers such as LYNX, we may never know there are capchas to fill out. Either the field never shows up or is not labeled. And as far as Cloudflare, because of that I haven't been able to read radiodiscussions for several years. At that time they whitelisted an IP but it didn't last.
Nothing's worse than accessibility theatre. Accessibility takes so much effort online, requiring careful attention to be paid to use cases that aren't trivial to test without literally setting up your system to be the way a blind person would have it. Now, that's not actually too bad, but there's no way to simulate it just from your browser's devtools that that immediately makes it out of the reach of people who don't want to install any extra software. Or use extra software once they've installed it.
They should figure out a better way to handle accessibility, but the browser doesn't provide a way to detect screen readers by design.
If you try to use these things, you may end up inadvertently blocking accessibility users anyway. Maybe there's a way to reliably distinguish bots from accessibility users, but it sounds unlikely given screen readers are effectively bots. Behavioral analysis should be part of an ensemble.
Captchas more often than not just make things harder for real living people who rely on accessibility tools. My only point of uncertainty is Cloudflare turnstile being "private" - this is Cloudflare we're talking about, one of the biggest internet MITM operations and gatekeepers on the internet. they're especially hostile towards any users on Tor or using privacy-enhancing configurations. I don't buy that anything they provide would actually be private, but to be fair I'm not making any strong or evidence-fueled argument here.
What do you think of options like mCaptcha and Anubis? I've especially seen the latter being used by some websites recently. github.com/mCaptcha/mCaptcha github.com/TecharoHQ/anubis
Altcha is a great alternative to traditional captchas. Just like Cloudflare Turnstyle, it's based on proof of work (POW), and works well for accessibility. There's an awesome implementation here: https://github.com/Flameborn/verity
I don't believe Cloudflare Turnstile ever shows a challenge, actually? Cloudflare's full-screen captcha interstitials used to, but haven't in a while.
I forgot where I read it, but someone reported great results in weeding out bots by adding "Reason" option buttons with a selected first option of something like "I'm a bloody bot, please ignore this message", and then some for legitimate reasons to contact them. Looks like most bots don't even evaluate these...
Captcha (most notably hCaptcha, but also reCaptcha) also don't work, or aren't reliable, if your browser isn't the latest version and/or doesn't support the latest tech.
This became a big issue for me when I was using a still-functional 12-year-old smartphone with an old OS. I wasn't submitting any forms, or sending anything - just browsing, reading. I'd say about 60% of the "mainstream" Internet became inaccessible to me - even when it was pure HTML and no JS - just because the website decided to use a captcha service on ALL requests, and my browser didn't understand how to process it (and the fact that it was sending a very old ident didn't help, it only made these systems more suspicious).
And the worst part is - the whole thing is DESIGNED to detect and block automation of ANY kind... which sometimes includes accessibility tools.
Though I'd advise caution with "behavioral analysis", because people with access difficulties will likely use the site in a way that is very different. If not done properly, this sort of approach could filter these people out simply because their use doesn't conform to "normal" patterns. YMMV.
One thing to keep in mind - the way we're going, browsers insist on more and more privacy, while companies dig deeper and deeper to identify users in ways that aren't outlawed yet (look up "canvas fingerprinting"...). Making the website aware that you're using a screen reader (or any other sort of accessiblity assist tools) may be considered "identifiable".
I understand that this is likely a tradeoff you'll happily make - but it's something to keep in mind, something that browser creators may need to take into account.
This could also be something malware might try exploiting? If it could decide that it's "safe" to run a more likely to succeed - but also much more VISIBLE - approach, because the user is expected to not see it due to being blind... I know this isn't very likely - but it's something that has to be at least considered?