Search topics
CAPTCHAs with no way past them except solving the puzzle
A ticket site's sign-in asks for the characters in a distorted image after two wrong passwords, with no audio version and no other way in, so people who can't see or read the image are stuck.
<img src="/captcha" alt="CAPTCHA"> The problem
People who can't see the distorted image, or can't make out its characters, can't sign in at all, because solving it is the only way in.
A concert ticket site asks for an email address and a password. After two wrong passwords, the sign-in page adds a box under them: an image of six distorted letters and numbers, a field labelled "Type the characters you see", and the Sign in button. The site added it to slow down programs that try password after password. A screen reader user who mistyped their password twice hears "CAPTCHA, image", then "Type the characters you see, edit text". The alt text says what the picture is, but not what it shows, which is the point of a CAPTCHA, and there is no audio version and no other way in. They can't buy the tickets. A sighted visitor with dyslexia can't tell whether it says "7KX4P2" or "7KX4PZ", and gets a new image for each wrong guess.
The same step fails in other ways:
- The image has no alt text at all, so a screen reader reads its file name, or nothing.
- A puzzle asks people to drag a piece into a gap, or to solve a sum, with no other way in.
- A grid of photos asks people to pick every picture with a bus, with no audio version and no way to skip it.
Success criterion 1.1.1, Non-text Content, is level A. A CAPTCHA is one of the few images whose text alternative doesn't have to say what it shows, since saying it would give the answer to every program. In its place, the criterion asks for two things: a text alternative that identifies and describes the CAPTCHA's purpose (technique G143), and another form of CAPTCHA that uses a different sense, such as audio beside an image (G144). This one has neither: "CAPTCHA" names the picture without saying what to do with it, and nothing but sight can get past it.
Success criterion 3.3.8, Accessible Authentication (Minimum), is level AA and new in WCAG 2.2. On a sign-in, reading characters from an image and typing them back is transcription, a cognitive function test, and no step of signing in may rely on one unless the step also offers a way in that needs none, or something that helps. The Understanding document says an audio CAPTCHA doesn't count as that alternative, because typing what you hear is transcription too. Recognising objects, such as picking out the buses, is an exception at this level; reading characters, sums and puzzles are not.
The CAPTCHA appears after a mistake, so it falls hardest on the people most likely to have just made one: those typing a password from memory, with a screen reader, a switch or an on-screen keyboard.
3 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (not affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Without vision A screen reader reads "CAPTCHA, image", then "Type the characters you see, edit text". The image's alt text names it but can't give the characters, and there is no audio and no other button, so a blind user can't sign in at all.
- Limited vision The characters are drawn thin, overlapping and crossed by lines on purpose, and zooming in only enlarges the blur, so someone with low vision often can't tell an O from a 0 or a 5 from an S.
- Limited language, cognitive and learning abilities People with dyslexia, or who find letters and numbers hard to hold and copy, have to read warped characters and type them back in order. Each wrong guess brings a new image, and on a sign-in, a few more can lock the account.
The image has alt text, so axe and other scanners pass it; none of their rules can tell that the alt text names a CAPTCHA rather than describing its purpose, or that nothing else on the page offers another way. The CAPTCHA here appears only after two failed sign-ins, so a scan of the page as it loads never sees it, and neither does EaseWeb's audit, which never mistypes a password on purpose. Where a CAPTCHA is on the page from the start, the audit lists up to five CAPTCHAs it recognises on each page it reaches, the common services' widgets and images whose address or alt text says CAPTCHA, as a lead: a person has to check whether a second sense is offered, and on a sign-in, a way in that needs no test. A code assistant asked to protect a form from bots may reach for a CAPTCHA widget first, and asked to make one accessible, can write alt text that spells out the characters, which hands the answer to every bot.
Try it
You have typed your password wrong twice. Try to sign in without looking at the picture.
The panel reads the form from the top, as a screen reader would. Is there a way past that needs neither sight nor solving a puzzle?
Broken Can you fix this?
Reading from the top, a screen reader says:
- Too many attempts. Type the characters below to sign in.
- Email, edit text, [email protected]
- Password, secure edit text
- CAPTCHA, image
- Type the characters you see, edit text
- Sign in, button
The fix
Stop bots behind the page, or give the CAPTCHA a second sense and a way in that needs no test.
- 1Keep CAPTCHAs off the sign-in where checks on the server can do the job.
- 2Describe a CAPTCHA's purpose in its text alternative, and offer it for another sense.
- 3On a sign-in, put a way in that needs no test beside any CAPTCHA.
<form action="/sign-in" method="post"> … <img src="/captcha" alt="CAPTCHA"> <label for="captcha">Type the characters you see</label> <input id="captcha" name="captcha"> <button type="submit">Sign in</button></form>No CAPTCHA, with attempts limited on the server
<form action="/sign-in" method="post"> … <!-- No CAPTCHA: the server limits attempts per account and per address. --> <button type="submit">Sign in</button></form>Why this fix: Stop bots without testing people
The … stands for the email and password fields, which stay as they are. The only way past is to see the image and read its characters: the alt text names it without saying what it is for, nothing offers the characters to another sense, and nothing lets people sign in without solving it.
The sign-in asks nothing more of anyone, so there is nothing to pass and nothing to fail. The CAPTCHA's job moves to the server: it allows a few wrong passwords for an account, then slows further attempts or locks the account until the person follows a link sent by email, and it limits how many attempts one address can make across all accounts. Those limits stop the programs that try password after password, without a test for the person at the keyboard.
The first two pass both criteria; the audio version alone passes 1.1.1 only. Take the CAPTCHA off: limits on the server stop the same programs, and the sign-in then has nothing to solve, where the second option still puts a test in front of everyone who doesn't notice the link. Keep a CAPTCHA only when a vendor or a policy you can't change requires it, and then give it all three parts. Use the audio version alone on a form that isn't a sign-in, such as a contact form, where 3.3.8 doesn't apply, and even there prefer checks that ask nothing of people.
Never put a CAPTCHA's answer in its alt text, its file name or the page: it gives the answer to the programs it is meant to stop. Describe what it is for, and let the audio carry the characters.
Make the audio controls a native audio element or a real button, reachable with the keyboard, and let the audio be played again: many people need to hear the characters more than once. Don't make the challenge expire while someone is listening.
CAPTCHA services that score each visit in the background ask nothing of most people, which helps; but check what they show the visitors they doubt, because that can be a picture puzzle like the ones above, and then it needs the same alternatives. A hidden field that only programs fill in, and limits on how often one address can send a form, do the same job on other forms.
Picking pictures of objects, such as buses or traffic lights, is excepted from 3.3.8 at AA, but it still needs a second sense under 1.1.1, and it fails 3.3.9, the AAA version, which has no such exception.
The rest of signing in needs the same care: a password field that refuses paste is the same failure of 3.3.8; see password fields that won't take a pasted password.
Fixing this with an AI coding assistant? Get this guide as Markdown, or get every guide in your coding agent.
Design ideas
A check for bots can look calm, and ask nothing.
Four ways to draw the step after two wrong passwords. Tab through them and try each one: two let everyone through without a puzzle, and two only look friendly.
In the design file
- Draw the sign-in without a puzzle first, and the bot check, if there is one, as a quiet line that asks for nothing.
- Draw the screen the check shows when it doubts someone too, because that screen is where people get stuck.
- Draw the way round the check at the same size and weight as the check, not as small grey text under it.
- Write beside each picture what it is for, such as “Characters to type, to check you’re a person”, for its alt text.
Passes
- A check that runs by itself A small status line works while the page is used and only says when it is done. Nobody sees, hears or solves anything, so there is nothing to give another sense or a way round.
Rule of thumb: Stop bots without testing people
- Two equal ways to go on The check and the way round it sit side by side as two cards of the same size, so nobody has to find a small link. One card offers the characters to see or hear; the other emails a sign-in link with nothing to solve.
Fails
- Slide the piece into the gapWCAG 3.3.8 It feels lighter than typing characters, but it is still a puzzle: matching a piece to a gap needs sight and a steady drag, it has no audio form, and on a sign-in 3.3.8 doesn’t except puzzles. Here the slider moves with the arrow keys too, which doesn’t change that.
- Pick every square with a busWCAG 1.1.1 Picking out objects is allowed under 3.3.8 at AA, so this looks like the safe choice. But the squares are only pictures, with no audio version beside them, so someone who can’t see them can’t start: 1.1.1 asks for a second sense.
Verify the fix
4 checks, no mouse.
Test with: Screen reader, Keyboard, Sound off, Screen off
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the CAPTCHA service, its settings or the sign-in form change.
Limits
This is a starting pattern, not a guarantee for every form. Every CAPTCHA shuts out someone: an audio version doesn't help people who are deaf-blind, and an emailed link doesn't help someone who can't reach their email, so the surest fix is not to ask people to prove they are people. 3.3.8 covers signing in; a CAPTCHA on a contact form or a checkout falls under 1.1.1, not 3.3.8, but it shuts out the same people. Test the whole flow, including what appears only after a mistake, with the tools your users rely on.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
References
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.