Short answer: not reliably, and the W3C has said so in a published note for years. Here is what WCAG actually requires, where implementations fail it, and what to use instead.
Accessibility is the argument against CAPTCHAs that does not depend on anyone's marketing. It is documented by the standards body that writes the accessibility guidelines, and it has been for a long time.
A CAPTCHA is non-text content, so it falls under WCAG 2.1 Success Criterion 1.1.1. That criterion requires two things of a CAPTCHA specifically: a text alternative describing what the test is for, and an alternative form of the test using a different sensory modality — an audio option beside a visual one, for instance.
So WCAG does not ban CAPTCHAs. It permits them on conditions that most real deployments either skip or satisfy in name only. That is the gap an audit finds.
The W3C's working group note Inaccessibility of CAPTCHA, maintained by the Research Questions Task Force of the Accessible Platform Architectures Working Group, states that "the very nature of the interactive task inherently excludes many people with disabilities, resulting in a denial of service to these users." Not poorly implemented ones: the task itself. Providing two modalities narrows the set of people you exclude. It does not empty it.
WCAG 2.2, a W3C Recommendation since October 2023, adds Success Criterion 3.3.8, Accessible Authentication (Minimum) at Level AA. No step of an authentication process may require a cognitive function test — remembering, transcribing, calculating or solving a puzzle — unless an alternative method or an assistive mechanism is available. A CAPTCHA at login is the textbook example, and the W3C adds that an audio CAPTCHA the user has to transcribe does not count as the alternative.
Two limits matter. It covers authentication, so a contact form that is not a login sits outside it. And at Level AA it exempts object recognition — the "select all the buses" grid — and tests built on personal content; the AAA criterion, 3.3.9, removes both exemptions. The EU's accessibility standard, EN 301 549, moved its baseline from WCAG 2.1 to WCAG 2.2 in a version published in September 2026 that was still awaiting citation in the Official Journal as this was written.
Government, nonprofit, education and regulated sectors are held to these rules by law rather than by choice. The full case — who a CAPTCHA excludes, what the research found, and the law by jurisdiction — is on the accessibility page.
That same study found audio CAPTCHAs particularly problematic — which matters disproportionately, because the audio track is the accommodation. The alternative offered to the users who most need it is the one that works least well.
Partly, and it introduces a subtler problem. A score-based invisible CAPTCHA removes the visible challenge for most visitors, which is a real accessibility improvement. But it does not make a decision — it hands your site a number, and you decide what happens below your threshold. That is almost always a fallback challenge.
The visitors most likely to score poorly are those on assistive technology, older hardware, unusual browsers, VPNs and privacy tooling. So the fallback challenge lands disproportionately on the people least equipped to complete it, while the median visitor never sees one and never reports a problem. The failure is invisible to you by design.
IP reputation is one of the inputs behind that score, and it is a signal in structural decline. IPv4's scarcity made a persistently bad IP mean something — an operator could not get many fresh ones cheaply. IPv6's address space is enormous by comparison, and allocations are trivial to obtain and rotate, so as adoption grows an IP address tells a scoring model less and less about who is actually behind it.
Replacing a CAPTCHA with a honeypot field has its own accessibility trap: a field
hidden only with CSS can still be announced and focusable for a screen reader user,
who fills it in and is silently rejected. Hide it from assistive technology too —
aria-hidden="true" and tabindex="-1". See
honeypot vs CAPTCHA.
The note is explicit that for both security and accessibility reasons, alternative methods should be preferred over a traditional image-based CAPTCHA, and it groups the options into stand-alone approaches you can deploy on your own host and multi-party approaches that involve a third party. In practice:
The common property is that none of them asks a person to demonstrate a sensory or cognitive capability in order to contact you.
SpamKill has no user-facing challenge to make accessible: it renders two versions of every form — clean for people, obfuscated for automated fillers — and scores the submission on behaviour, at 99.9% accuracy across more than 100M+ submissions screened for 1,500+ businesses. The obfuscation targets automated parsers, not assistive technology; screen readers get the clean form. When we are unsure about a real person they verify in one step, in any of 13 languages, and continue, and anything held is recoverable rather than deleted. From $29/month with a 30-day free trial, no credit card.
No. WCAG 2.1 Success Criterion 1.1.1 treats a CAPTCHA as non-text content, which means it needs a text alternative describing its purpose and an alternative form of the test using a different sensory modality — typically an audio option alongside an image one. So a CAPTCHA is permitted, but only with alternatives most implementations either skip or implement badly. WCAG 2.2 goes further at login: Success Criterion 3.3.8 bars a cognitive function test (transcribing, calculating, solving a puzzle) from any step of authentication unless an alternative or an assistive mechanism is available, though it covers logging in rather than contact forms, and exempts object-recognition tests at Level AA.
It satisfies the letter of the requirement and often not the intent. The W3C says the interactive task "inherently excludes many people with disabilities", and audio challenges do not help someone who is deaf-blind, or someone with an auditory processing difficulty. It also does nothing for cognitive load, which is where many users actually fail.
It removes the visible challenge for most users, which genuinely helps. But it scores a visitor and hands your site a number, and what happens below your threshold is your decision — usually a fallback challenge. The people most likely to score badly are those on assistive technology, older devices, unusual browsers and privacy tooling, so the fallback lands disproportionately on the users least able to complete it.
The W3C note explicitly prefers alternatives to traditional image CAPTCHAs, and groups them into stand-alone approaches you can deploy yourself and multi-party approaches involving a third party. In practice that means server-side heuristics, behavioural analysis, and multi-step or multi-device verification rather than a visual Turing test.
It is a plausible risk rather than a certainty, and it depends on your jurisdiction and sector. What is not in dispute is that a CAPTCHA without a working alternative fails a documented WCAG success criterion, and that is the sort of finding an audit records plainly. We are not lawyers — if you operate under a specific accessibility obligation, take advice on your own situation.
Paste your form HTML into the Form Transformer and see what a visitor receives — no challenge, no fallback, nothing to fail.
Open the Form Transformer