CAPTCHA accessibility and alternatives

A CAPTCHA is a test meant to confirm that a person, not a program, is using a site. The name is an initialism for "Completely Automated Public Turing test to tell Computers and Humans Apart", as W3C's Understanding document for 1.1.1 notes. Most ask the visitor to read distorted text, pick the images that contain an object, or listen to a clip. W3C says CAPTCHAs intrinsically push the edges of human abilities, so every type is unsolvable by people with certain disabilities. That makes the answer a design decision before it is a coding one: ask for a challenge only where you must, and give people another way through where you do.

This is general information, not legal advice. For the fields around the challenge, see our accessible forms guide, and for the wider picture see how to make a website accessible.

Why CAPTCHAs exclude people

The W3C note Inaccessibility of CAPTCHA is the standards body's fullest treatment of the problem. It is a Group Draft Note dated December 16, 2021, and it says it is not endorsed by W3C or its Members and may be updated, replaced or obsoleted. Its abstract says interactive tasks inherently exclude many people with disabilities, and that research findings indicate many popular CAPTCHA techniques are no longer particularly effective or secure. In summary, the note describes:

• Visual challenges. A screen reader cannot read a distorted image, and the note says a CAPTCHA image cannot carry useful alternative text. Distortion also hurts people with low vision, dyslexia, and cognitive or learning disabilities, and a challenge that assumes the reader knows English excludes others.
• Audio challenges. Robots can recognize speech, so audio is distorted too, which makes it hard for people as well. It plays over time, and the note says few audio CAPTCHAs offer an easy, reliable replay, let alone an independent volume control or a pause. It shuts out people who are deaf-blind, have no sound hardware or are in a noisy room, and it adds cognitive load.
• Repeated attempts. The note calls a design that expects multiple attempts arguably inaccessible by design for people with an anxiety disorder and many with other cognitive or learning disabilities.
• An arms race. Making a puzzle harder for software also makes it harder for people, which is why a stronger CAPTCHA is not the fix.

What WCAG requires of a CAPTCHA

Three success criteria bear on CAPTCHAs. The first applies to any CAPTCHA, the other two to logging in. See conformance levels for what A, AA and AAA mean.

1.1.1: a description and a second sense

W3C's Understanding 1.1.1 explains why the text alternative only describes the CAPTCHA's purpose. An alternative that solved the puzzle would let robots operate it, which defeats the point. So the weight falls on the second half of the criterion: another form of CAPTCHA that uses a different sense. W3C says requiring two different forms of CAPTCHA on a site ensures that most people with disabilities will find a form they can use, and it admits that some people will still be shut out. The sufficient techniques are G143, a text alternative that identifies the content as a CAPTCHA and names the task, and G144, another CAPTCHA with the same purpose in a different modality. W3C says G143 is sufficient only together with G144. In our reading, a picture-only challenge falls short however good its alt text is.

3.3.8: no puzzle at login without another way in

3.3.8 is new in WCAG 2.2 (see what's new in WCAG 2.2). Its Understanding page defines a cognitive function test as a task that requires the user to remember, manipulate or transcribe information. A login step may require one only if the step also offers another method that does not rely on one, or a mechanism that assists the user (W3C names password managers and copy and paste), or if the test is to recognize objects or to identify non-text content the user provided to the site.

The two criteria can disagree. A distorted-text CAPTCHA with an audio alternative can meet 1.1.1, because the second form uses another sense. At a login, W3C says an audio clip the user has to transcribe cannot meet the Alternative exception, because transcribing is itself a cognitive function test. The table shows how common challenges fare at a login step.

Which challenges 3.3.8 covers

W3C's page says the criterion focuses on authentication of existing users and does not cover creating a username or starting an account. It applies to a test even when the test appears only in some situations, such as when an ad blocker is present. The page says nothing about CAPTCHAs on other forms, such as contact forms, comments or checkout. Those still fall under 1.1.1. In our reading, offer the same alternatives there anyway, because a form that blocks a person blocks them wherever it is.

Accessible alternatives to puzzle CAPTCHAs

The W3C note sorts alternatives into stand-alone approaches, which a site can deploy without a third party, and multi-party approaches, which rely on a third party. The table summarizes what it says about each, with puzzles for contrast.

The note's conclusion is that there is still no single, ideal solution. Its recommendations, in summary: assess the risk first and do not force users beyond what is necessary; minimize how often anyone faces an interactive challenge; where one is needed, offer several types so users can choose; all else being equal, prefer non-interactive approaches, which pose no accessibility challenge but may expose users to personal data collection; and weigh third-party verification against its privacy trade-offs.

The note is from 2021 and says an effective system today may prove ineffective in a few years. It reports that keyboard use with the checkbox version of one large provider's service, once regarded as the most accessible, was widely observed to bring up a traditional, inaccessible CAPTCHA as a fall-back, and that for its non-interactive version the response to an ambiguous score is left to the site. A risk-score check is only as accessible as its fallback. Test the current version of whatever you choose with a keyboard and a screen reader before relying on it.

Hiding a honeypot properly

A honeypot has to be invisible to people, including people who use a screen reader or the keyboard. MDN says the HTML hidden attribute hides an element from all presentations, screen readers included, and that a CSS display value on the element overrides it. MDN does not cover keyboard focus, so Tab through the form to confirm focus never lands in the field. In our reading, a field that is only moved off screen can still be read aloud and filled in by a person, who is then treated as a robot.

Make the login pass 3.3.8

The login is where the criterion bites, and most of the fixes are small. W3C's Understanding page names these:

• Let browsers and password managers fill the fields. Properly marked-up username and password inputs are W3C's technique H100.
• Never block paste or change the format. W3C says blocking paste into a login field forces transcription and fails the criterion unless another method is available. Failure technique F109 covers asking for a password or code in a different format from the one it was created in, such as only the 2nd, 6th and last characters, or one digit per box that will not take a pasted code.
• Let people paste verification codes. W3C says a service that requires manual transcription of a verification code does not meet the criterion, and that it must at least be possible to paste the code and let the browser fill the field.
• Offer a route with no test. W3C's examples and techniques include an emailed sign-in link (G218), WebAuthn using the device's own method, login through a third-party OAuth provider, a USB device the user activates with a button press, a QR code scanned by an app, and a device prompt approved with the device's own authentication.
• Offer a show-password option. W3C notes it can improve the chance of success for some people with cognitive disabilities or who have difficulty typing accurately.
• Cover every step. W3C says each step of a multi-step or multi-factor login must meet the criterion, and account recovery needs a route without a test too.

If you keep a challenge

• Describe it in text. Say that it is a CAPTCHA and what task it asks for, and where to find the other form, without giving the answer (G143).
• Offer two forms that use different senses (G144), or more than two as W3C recommends, and at a login make sure one route needs no transcribing or solving.
• Add a human route. W3C recommends going past the minimum: access to customer service that can bypass the challenge, and no challenge for authorized users.
• Keep what the visitor typed. After a failed attempt, we suggest keeping the form's contents and saying in text what went wrong; our guide to accessible error messages covers the wording.

Check it yourself

Whether a person can get past a challenge is a manual check. Our WCAG criteria reference marks 3.3.8 as needing a person to walk through the sign-in process. Set aside ten minutes:

1. List every challenge. Check sign-in, sign-up, password reset, contact, comments and checkout. Try a private window, an ad blocker and repeated wrong passwords, since W3C notes that some challenges appear only in situations like these.
2. Use the keyboard only. Reach the challenge, complete it and move on, as in our keyboard accessibility test.
3. Use a screen reader. Can you tell what the challenge is and find the second form? Our guide to testing website accessibility covers the setup.
4. Count the ways through. Is there a second sense, a human route, or a login method that needs no puzzle? Is any audio route one you must transcribe?
5. Paste and autofill. Paste a password and a code, and sign in with a password manager.

The WCAG audit checklist tracks 1.1.1 and 3.3.8 among the 55 Level A and AA criteria and exports CSV. The free scan reads the HTML your server sends, so a widget that a script builds is not in it, and no scan can tell whether a person can solve a challenge (see what we check). The accessibility bookmarklet reads the page as your browser rendered it, but its limits list says frames from other sites cannot be inspected. For the rest of the page, Scan my site for free.