CAPTCHA accessibility: what the WCAG and the W3C say

Why is a CAPTCHA an accessibility problem?

Because a test assumes an ability: seeing, hearing, reading, remembering, aiming precisely. A CAPTCHA that relies on only one of them shuts out the people who lack it, at the very place where the visitor wants to write, sign up or log in.

See: Glossary: CAPTCHA

What does WCAG 2.2 say about CAPTCHA?

WCAG 2.2 is a W3C Recommendation, first published on 5 October 2023; the version read here is the one of 12 December 2024. Two of its criteria touch CAPTCHA. The quotations below are the English text, which prevails (the French page quotes the French translation published by the W3C).

Success Criterion 1.1.1, “Non-text Content” (Level A), requires a text alternative for all non-text content, except in the situations it lists. The one for CAPTCHA: “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.”

Success Criterion 3.3.8, “Accessible Authentication (Minimum)” (Level AA): “A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:” (each is introduced by its name in the standard)

• Alternative: “Another authentication method that does not rely on a cognitive function test.”
• Mechanism: “A mechanism is available to assist the user in completing the cognitive function test.”
• Object Recognition: “The cognitive function test is to recognize objects.”
• Personal Content: “The cognitive function test is to identify non-text content the user provided to the website.”

The W3C’s Understanding document draws this consequence: if a CAPTCHA is part of an authentication, there must be a method without a cognitive function test, unless the test falls under an exception. Object recognition and personal content are exceptions at Level AA, but not at Level AAA (criterion 3.3.9), and the document recommends avoiding them if possible. An audio alternative that has to be transcribed does not meet the “Alternative” exception.

Criterion 3.3.8 is about logging in to an existing account: the Understanding document states that it covers neither the creation of a username nor the opening of an account. Criterion 1.1.1 is about the non-text content of a CAPTCHA, wherever it is, including in a contact form.

What does the W3C say about alternatives?

The W3C’s Accessible Platform Architectures Working Group wrote a note, “Inaccessibility of CAPTCHA”. The version read is a draft note of 16 December 2021: neither the W3C nor its Members have endorsed it, and the document states that it should be cited only as work in progress. Its conclusions, summarised:

• a visitor should not be put through more tests than the security of the site strictly requires;
• when an interactive CAPTCHA is judged necessary, it is very beneficial to limit as much as possible how often it is shown, and several alternative tests must be offered, engaging different sensory and cognitive capabilities;
• the W3C prefers approaches without interaction, which pose no accessibility difficulty; they may, however, expose the user to the collection of personal data;
• there is no single, ideal solution: the purpose and effectiveness of any CAPTCHA deployed must be considered before adopting it, then closely monitored.

What should you do in practice?

• Remove the test when you can: validation on the server, limits on submissions and an invisible bot check (sometimes called an “invisible CAPTCHA”) ask nothing of the visitor.
• If you keep a CAPTCHA, offer several forms of test, and on a login a way to do without it.
• Provide another way to reach you when a submission is refused: an e-mail address, for example.
• Test with the keyboard alone and with a screen reader, then follow the wrongful refusals after going live.
• Look at what a check without a test measures: the W3C reminds us that it may expose personal data.

See: Glossary: invisible CAPTCHA · Frequently asked questions: can Antisy block real visitors? · Documentation: data collected and privacy

Where Antisy fits in

Antisy shows the visitor nothing: no box to tick, no puzzle. There is therefore no test to make accessible. That does not make a form accessible, and Antisy does not say that your form meets the WCAG: the labels, the contrasts and the keyboard navigation remain those of your form.

The check has its own limits, which the site states. The browser does a short computation in the background: a very slow device that does not finish it in time is refused, whatever the mode. If the script is blocked, the form is sent without a token, and a submission without a token does not pass when browser collection is on for the site. The answer is allow or deny, with no reason: it is up to you to provide a refusal page that offers another way to reach you.

Antisy announces no detection rate.

See: Frequently asked questions: what is the difference between Antisy and a CAPTCHA? · Glossary: background computation · Documentation: if the script does not run · Documentation: a real visitor is refused · Documentation: how strictly to refuse · Home page: what the script measures, and for how long

Where does Antisy stand?

Access is by waiting list. The API and the dashboard have been in service since 27 October 2026, hosted at Infomaniak in Geneva; no customer is in production yet. The pilot started on 9 November 2026 on our own forms.

See: The pilot · Join the waiting list

Frequently asked questions