The CAPTCHA That Keeps Real People Out

ClearPath Team · 2026-09-29 · 6 min read

A CAPTCHA has one job: tell humans and bots apart. The awkward truth is that a lot of CAPTCHAs are better at stopping humans. Bots have gotten very good at reading warped text and picking out traffic lights. Many people haven't, and some never could.

If your contact form, signup page or login uses a puzzle to check that the visitor is a person, it's worth asking which people it's keeping out.

Who gets locked out

The classic distorted text CAPTCHA is unusable for a blind visitor, because there's nothing for a screen reader to read. Audio alternatives were added to fix that, but they're often so noisy that sighted testers struggle with them too, and they don't help someone who is deafblind.

Image grids aren't much better. Picking every square with a bicycle assumes good vision, good color perception and a steady hand for tapping small targets. For someone with low vision or a tremor, a grid of tiny, blurry thumbnails is hard work.

Then there are the people nobody thinks about when they add the widget: visitors with dyslexia, memory impairments or other cognitive disabilities, and people reading in their second language. Transcribing a string of random characters, or remembering one while switching focus to a text box, is exactly the kind of task that trips them up. Getting it wrong three times and being told you might be a robot doesn't help.

What WCAG 2.2 says now

WCAG 2.2 added a success criterion aimed squarely at this. 3.3.8 Accessible Authentication (Minimum), Level AA, says that a step in a login or authentication process shouldn't depend on a cognitive function test, meaning things like remembering a password, solving a puzzle or transcribing characters, unless the site also offers a way around it.

Acceptable ways around it include:

• An alternative method that doesn't need the test, such as a passkey, a sign-in link sent by email, or signing in with an account the user already has.
• A mechanism that helps, like letting the browser or a password manager fill the field, and allowing paste. Blocking paste on a password or code field is one of the easiest ways to fail this criterion.
• Object recognition or personal content, like identifying a photo the user uploaded. These are allowed at Level AA, though the stricter AAA version (3.3.9) removes that exception.

Strictly speaking 3.3.8 covers authentication. A CAPTCHA on a plain contact form falls under an older requirement instead, 1.1.1 Non-text Content, which says a CAPTCHA needs a text description of its purpose and an alternative in a different sense, so a person who can't see it can still get through. In practice the advice for both lands in the same place: don't make a puzzle the only way in.

Better ways to stop bots

The good news is that most sites can drop the visible puzzle entirely without letting the spam back in. Options worth looking at:

• Invisible or proof-of-work checks. Several services now verify visitors in the background by having the browser do a small computation or by looking at behavior signals, with no puzzle shown to most people. Check that the fallback, when one does appear, is accessible too.
• Honeypot fields. A hidden field that humans never see and bots fill in. Make sure it's hidden from screen readers as well as visually, or you'll trap the exact users you're trying to help.
• Rate limiting and server-side filtering. Much of the spam a CAPTCHA catches can be stopped by limiting how often one address can submit, plus a decent spam filter on the backend.
• Email or SMS codes for sign-in. A one-time code the user can paste, or a magic link they just click, is both friendlier and harder for a bot to fake at scale.

Whatever you pick, test it the way a real visitor would. Try your signup with only a keyboard. Try it with VoiceOver or NVDA. Try pasting a password from a password manager. If any of those fail, you've found your barrier. No widget, ClearPath included, can run this test for you, because an automated tool can't tell that a real person gave up on step three.

The visitor side of the problem

Some parts of a form experience can be eased from the visitor's side even while the underlying fix is on your roadmap. ClearPath lets visitors enlarge text, increase spacing, switch to a more readable font and turn on a reading guide, which helps someone with dyslexia or low vision work through the rest of a long signup form. It won't solve the CAPTCHA itself, though. A widget can't pass a puzzle for the user, and it shouldn't try: that's exactly what the puzzle exists to prevent.

Spam is a real problem, and nobody wants a contact inbox full of junk. But a CAPTCHA that blocks one in fifty real customers is an expensive filter. Swap the puzzle for something invisible, keep a human-friendly fallback, and test it with the people it was blocking.