CAPTCHAs exclude users. The honest design question isn’t whether they exclude anyone — they all do — but how many, who, and what fallback paths you’re willing to ship. This article is the design constraint sheet we use internally, generalized so you can apply it to whatever CAPTCHA you build, integrate, or evaluate.
The honest truth about CAPTCHA accessibility
Every CAPTCHA design has a population it locks out:
- Image-grid CAPTCHAs exclude blind and low-vision users almost completely. Audio fallbacks help but the failure rate is much higher than for sighted users.
- Audio CAPTCHAs exclude deaf users without an alternative.
- Drag-and-drop puzzle CAPTCHAs exclude users with motor impairments, screen-reader users, and many users on mobile assistive tech.
- Game-based CAPTCHAs (Playtcha included) require enough motor control to play, enough vision to see the canvas, and enough cognitive bandwidth to understand the challenge.
- Behavioral CAPTCHAs exclude users on assistive tech that doesn’t produce “normal” mouse traces. They also exclude users on locked-down browsers because the fingerprint signal looks abnormal.
- Proof-of-work CAPTCHAs exclude users on the cheapest Android hardware where the puzzle takes 10+ seconds.
There is no design that includes everyone. The work is in choosing the smallest exclusion set, providing meaningful alternatives, and being honest in your accessibility statement about the gaps.
The WCAG anchors that actually apply
WCAG 2.2 has one CAPTCHA-specific success criterion and several criteria that bear on it indirectly. The anchor:
1.1.1 Non-text Content (Level A): If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
Plain reading: if you ship a visual CAPTCHA, you must ship at least one non-visual alternative. If you ship an audio CAPTCHA, you must ship at least one non-audio alternative. The full criterion is in the WCAG 2.2 spec and is the canonical reference.
The criteria that bear indirectly:
- 2.1.1 Keyboard (Level A) — every interaction must be reachable from a keyboard.
- 2.2.1 Timing Adjustable (Level A) — if your CAPTCHA times out, the user must be able to extend or cancel the timeout, with limited exceptions.
- 2.5.1 Pointer Gestures (Level A) — single-pointer operation must be sufficient (no required multi-touch).
- 3.3.1 Error Identification (Level A) — when verification fails, the user must be told why.
- 4.1.3 Status Messages (Level AA) — “solved” / “failed” states must be announced via ARIA live regions.
Hitting Level AA on the indirect criteria is achievable for any CAPTCHA with care. Hitting 1.1.1 is the design problem because it forces you to ship at least two modes.
Screen-reader paths
Screen-reader users are the population most often abandoned by CAPTCHA design. The three things that make a screen-reader path usable:
1. The widget surfaces its purpose, not its mechanics
The element that mounts your CAPTCHA should announce something like “Verification: confirms you’re a human, not a bot. Press Enter to start.” Not “Click on all the buses,” not “flap the bird through the pipes.” The screen-reader user needs to know why the widget exists before they need to know how to operate it.
2. There is an audio alternative that is actually usable
The classic image-grid + audio fallback is poor design. Audio CAPTCHAs are notoriously hard — distorted speech in a single language, with a high abandonment rate documented in academic studies. Better designs ship a screen-reader-native challenge (e.g. an audio sequence the user repeats with the keyboard) that was designed from scratch as the primary path for that user, not as a fallback hammered onto a visual primary.
3. The completion event is announced
When verification succeeds, an ARIA live region must announce “Verified” or equivalent. When it fails, the same live region announces the failure with a clear next action. A screen-reader user staring at a silent submit button after completing your CAPTCHA is one of the most disorienting failure modes in modern web UI.
Motor and dexterity considerations
Motor-impairment exclusion gets less attention than vision exclusion but affects more users. Key constraints:
- No required multi-touch. Single tap, single click, single key press. Pinch-to-zoom, two-finger swipe, rapid double-tap — all exclude users with limited dexterity, intention tremor, or assistive pointers.
- No precision targets smaller than 24×24 CSS px. WCAG 2.5.8 (Level AA in WCAG 2.2) sets this floor for pointer targets. CAPTCHAs with hit-targets smaller than this exclude users on touch.
- No required reaction time below ~800ms. Anything faster excludes users with slower motor response. If your game requires snap reflexes, you have a population to design around.
- No required sustained input. “Hold the button for 3 seconds” excludes users who can’t reliably maintain pressure.
- Keyboard parity. Every game action reachable by mouse or touch must be reachable from a keyboard. This is non-negotiable for WCAG compliance and is also good design.
We discuss the per-game constraints we apply at Playtcha in the public design specs. The short version: every game must be playable in <10 seconds, single-pointer, single-modality.
Cognitive load and time pressure
WCAG doesn’t set explicit cognitive-load criteria, but cognitive accessibility is a live research area and the patterns are clear. Things that exclude cognitive-disability users from CAPTCHA flows:
- Time pressure. “Solve in 10 seconds” excludes anyone whose processing speed is slower than the timer assumes.
- Multi-step instructions. “Identify the buses, then the traffic lights, then the bicycles” is three CAPTCHAs.
- Ambiguous categories. Is a school bus a “bus”? Is the front of a bus a “bus” if the wheels aren’t in frame? These are well-documented failure modes for image-grid CAPTCHAs.
- Idiomatic English. CAPTCHAs that say “Are you a robot?” assume cultural and linguistic context that not every user has.
The mitigation pattern is: short, clear, single-step, time-flexible, with a visible “skip and try a different challenge” button.
Time pressure that isn’t obvious
Many CAPTCHAs surface a visible countdown timer, which is at least honest. The subtler problem is the invisible timer baked into many designs — the one that fails the user silently if they take more than 90 seconds. Users with cognitive disabilities, users who got interrupted, users on a slow assistive tech setup all hit this without warning. The right design either removes the invisible timer entirely or makes it visible and adjustable, per WCAG 2.2.1.
The fallback question
Even with a great primary CAPTCHA and a great accessibility-mode CAPTCHA, you will have users for whom both fail. The question is what you do for them. Three honest answers, in order of cost:
The email-link fallback
Replace the CAPTCHA gate with a “send me a verification email” button for any user who self-identifies as unable to complete the CAPTCHA. The email contains a single-use link that lets them proceed. Cost: an extra email, an extra round trip. Benefit: a fully-accessible path that doesn’t require the user to disclose a disability.
The ID-verification fallback
For high-trust applications (financial, healthcare), a manual identity-verification flow can substitute for the CAPTCHA entirely. Higher friction, higher cost, but bulletproof for users who can’t complete any automated challenge.
The honest opt-out
The smallest fallback: a contact email and a 24-hour SLA for manual account creation. Doesn’t scale, but is non-negotiable for any service that takes accessibility seriously.
At minimum, your accessibility statement should name your fallback path and give the user a way to invoke it without having to ask permission. WebAIM has a strong write-up of the broader accessibility-of-CAPTCHAs literature if you want the academic context.
The opt-out, in copy
The wording of your fallback prompt matters more than teams expect. The bad version: “Can’t solve the CAPTCHA?” — implicitly blames the user. The good version: “Use a different verification method” — treats the alternate path as first-class. The ugly version: burying the fallback inside a help article. Disability-rights users have written extensively about how the language of accessibility opt-outs reflects how seriously the design treats them. The link should be the same visual weight as the primary control, on the same screen, in plain English.
Where Playtcha is today
We’ll be specific about what Playtcha currently ships and what we don’t.
The decision we’re proudest of and the decision we’re least proud of are the same: shipping with the post-MVP fallback path open. We chose to launch with three accessible games and a documented gap, rather than wait for a perfect solution we can’t define yet. That trade ships value to the 95% of users it works for; it leaves users in the gap with a workaround that is honest but slow. We don’t pretend that’s good enough long-term. We publish the gap so users in it can hold us to closing it.
What we ship
- A rotated set of short visual games that are designed to finish in seconds on mobile and desktop.
- Keyboard parity on all games (arrow keys + space).
- Touch-first interactions with mobile-safe hit testing and drag targets in the widget shell and games.
- Focus management plus ARIA live announcements on loading, success, retry, and failure states.
- Per-game screen-reader score/status announcements where the widget already exposes them.
- A public accessibility statement at
playtcha.com/accessibility.
What we don’t ship yet
- A true audio-only gameplay mode for blind users. The current widget is still primarily visual.
- An email-link or manual fallback for users who can’t complete the visual games. That is still the largest known accessibility gap.
- Localized audio mode beyond English (blocked on shipping audio mode at all).
- A “simple mode” for users with cognitive disabilities — currently the same challenge for everyone.
We publish this list because pretending the gaps don’t exist is worse than naming them. Any vendor who tells you their CAPTCHA is “fully accessible” without an enumerated gap list is selling you something.
Related: the broader question of whether you should ship a CAPTCHA at all, in why use a CAPTCHA. The comparison of vendors’ accessibility postures, in reCAPTCHA alternatives. The privacy posture that pairs with not behavioral-tracking users on assistive tech, in privacy-first CAPTCHAs explained. The implementation walkthrough that includes the screen-reader considerations in the form, in CAPTCHA with Supabase. Accessibility statements live next to your DPA in a procurement pack — see the GDPR CAPTCHA checklist for the rest of that pack.
FAQ
Are reCAPTCHA and hCaptcha WCAG-compliant?
Both ship audio fallbacks for the image grid, which is the minimum for WCAG 1.1.1 compliance. Whether the fallback is actually usable is a separate question. Independent accessibility audits have generally rated both as “passes the letter but not the spirit” of WCAG.
Does Playtcha have a screen-reader mode?
Not yet in the full sense. The widget does ship keyboard controls, focus management, and polite live-region updates. But it is still a visual minigame product, and a true non-visual completion path is still work we need to build.
What about users on Switch Access or eye tracking?
Switch Access works because every action is keyboard-reachable and every game has at least one game playable with a single input. Eye-tracking input is more variable; we’d like to hear from anyone using Playtcha through eye tracking so we can tune for that population specifically.
Doesn’t requiring a game inherently exclude some users?
Yes. We’re honest about that. The post-MVP fallback for users who can’t play any game is the email-link path described above. Until that ships, the workaround is a contact-form opt-out — which is a worse experience than we want to ship long-term, but is at least an opt-out.
Where can I file an accessibility complaint?
Email us. Every accessibility report goes to a single tracked inbox. We treat them as Sev-2 by default, with an SLA in our public support docs.
