Your compliance dashboard says this page passes. Meanwhile, your customer is sitting on it right now, unable to buy anything.
The culprit is the box asking them to prove they're human. It's also the barrier most likely to survive your entire compliance process intact, because an automated scan won't report it. The page is clean. The purchase doesn't happen.
If you sell into the European Union (EU), this sits directly in the flows the European Accessibility Act (EAA) cares about: checkout, account creation, contact forms. So it's worth being precise about what the rules actually say, why the usual "accessible alternative" isn't one, and what to use instead.
The WCAG exemption is narrower than most teams think
Completely Automated Public Turing Test To Tell Computers and Humans Apart (CAPTCHA) is permitted under Web Content Accessibility Guidelines (WCAG), but that permission comes with conditions that are routinely missed.
You need a text alternative that identifies and describes the purpose of the challenge, and you need alternative forms using different modes of sensory perception, so that people with different disabilities have a way through. That wording comes from WCAG's Alternative Text criterion (1.1.1), the same one that governs every image on your site.
The exemption applies only to the content of the CAPTCHA and everything around it still has to conform in full. The visible label. The accessible name. The focus order. The error message when it fails. Any time limit on completing it.
In practice, most implementations fail on those before anyone reaches the puzzle. An unlabeled iframe, a failure message that never reaches a screen reader, a challenge that expires while a user is still working through it — none of that is covered by the exemption.
EN 301 549, the standard the EAA points to, incorporates WCAG. The revision expected in the Official Journal later this year moves that baseline from WCAG 2.1 to 2.2. Either way, the requirements above apply now.
Audio CAPTCHA is not the accessible option
It's the reflex answer, and it doesn't hold.
Audio challenges exclude people who are deaf or hard of hearing, and anyone with an auditory processing disorder. They add cognitive load through deliberate background noise. Users repeatedly report them as harder than the visual version, and often as practically unusable.
Then work through the combination. Visual for people who can't see. Audio for people who can't hear. A customer who is deafblind gets neither.
Adding an audio track doesn't make a CAPTCHA accessible. It makes it inaccessible to a different group.
The security case has quietly collapsed
W3C's working note on the inaccessibility of CAPTCHA states that many popular CAPTCHA techniques are no longer particularly effective or secure.
Character-based challenges fall to optical character recognition and pattern-matching attacks. One study cracked Google's audio reCAPTCHA at a 90% success rate using Google's own speech-to-text service. Puzzle challenges are readily defeated by crowd-sourced human solvers working for the attacker.
As characters get more distorted to resist machines, they get harder for humans with perfectly good vision, which is what makes the whole approach impractical rather than merely imperfect.
Meanwhile your customer with a tremor, low vision, or dyslexia is still stuck at the gate.
That's a checkpoint that stops humans and waves through machines. Before spending money making it accessible, it's worth asking whether it earns its place at all.
Start with controls the user never sees
The goal is to raise the attacker's cost without transferring that cost onto people with disabilities, and that comes from layering cheap invisible measures, not from finding one perfect widget.
For a typical small and medium-sized enterprise (SME) contact form or signup, these four together eliminate the large majority of spam with no user-facing friction:
Honeypot fields. A decoy input that bots fill in and humans never see. W3C's note recommends these as a first resort, and they're supported natively in Drupal and in several WordPress plugins.
The trap is an accessibility one, and it's in the middle ground. Hiding the field with display: none removes it from screen readers and the tab order together — that's safe. Positioning it off-screen while leaving it in the accessibility tree is not: a screen reader user meets a field with no explanation, fills it in, and gets rejected as a bot.
There's a second pattern worth knowing. Rather than hide the field, leave it perceivable and label it honestly. W3C documents Hilton's implementation, which uses a focusable field labeled to the effect of "this field is for robots only, please leave blank." Less elegant, but it fails safe.
A submission timing floor. Forms completed in under a second or two are automated. Use a minimum only, not a maximum. Plenty of people take longer to complete a form; someone tabbing through field by field with a screen reader, someone using switch access, or someone re-reading the instructions. Adding an upper limit pulls you into Timing Adjustable (2.2.1) — requiring you to allow users to turn the limit off, adjust it, or extend it.
Rate limiting. Server-side, per IP and per endpoint. Be careful limiting by IP address alone because mobile networks often put many customers behind one shared address, so a strict limit can block a real customer along with the bot.
Server-side content filtering. Score submissions after the fact rather than gating them beforehand. You need a real route for people wrongly filtered to reach you — which is also, separately, an EAA obligation.
Challenge the machine, not the person
If the invisible layer isn't enough for your risk profile, the next step is a challenge the device completes rather than the user.
Proof-of-work. The browser performs a small computation instead of asking the user to identify images. W3C's assessment is that this poses no direct accessibility problem, since there's no sensory or cognitive task at all. ALTCHA is the open-source implementation most people reach for, and markets itself as cookie-free and non-tracking; verify that against its current documentation before you repeat it to a client.
Two caveats. It's slower on older, low-power hardware, and you shouldn't assume everyone is on a current device. The widget also needs to announce its own state through a live region — verifying, verified, failed — or a screen reader user is sitting at a control that appears to do nothing.
Token-based attestation. The device vouches for the user; no challenge is shown at all. Cloudflare's cryptographic attestation of personhood is the best-known example. Excellent when it works. It excludes people on older operating systems and non-attestable platforms, so what matters is the quality of the fallback, not the mechanism.
The mistake almost everyone makes with invisible verification
Risk-based systems score traffic and escalate anything that looks unusual.
Screen reader use. Switch access. Keyboard-only navigation. Screen magnification. VPNs. Older browsers. All of it generates atypical signals.
So the users most likely to be flagged as suspicious are the ones least able to pass the hard challenge they get escalated into.
This isn't hypothetical. W3C documents keyboard navigation ceasing to work in reCAPTCHA v2, with users dropped into a traditional inaccessible CAPTCHA as the fallback. In fact, browsing in incognito mode or blocking cookies can be enough to trigger it.
Invisible verification is not accessible because it is invisible. It is accessible only if the escalation path is accessible. Test that path deliberately, because your vendor's demo will show you the happy case.
Four questions to put to any vendor
What exactly does a flagged user see, and can I trigger that state on demand to test it?
Is the fallback ever image or audio identification only?
What is announced to a screen reader at each state change?
Is there any time limit on completing the challenge?
If a vendor can't force the failure state for you to test, you can't verify their claim. "WCAG compliant" on a pricing page is a marketing assertion, not an audit.
The test to run this week
Open your own checkout. Turn on a screen reader. Tab to the CAPTCHA and complete the purchase.
If you can't, neither can your customers.
Twenty minutes, costs nothing, and closer to what a court would actually look at than any dashboard percentage. This is manual testing in its cheapest possible form.
Not sure whether your forms are in scope? The EAA readiness scorecard takes five minutes and needs no site access.