Search topics
Sign-ins you can only pass by picking pictures
A bank's sign-in asks people to pick every picture with a bus, or the photo they uploaded when they opened the account, and offers no other way to finish.
<legend>Choose the photo you uploaded</legend> The problem
People who can't make out the pictures, or can't remember which photo was theirs, can't finish signing in, because picking pictures is the only way through
A bank's sign-in asks for an email address and a password, then shows one more step before the account opens. Banks build that step in two common ways, and both end the same way.
The first is a bot check. Visitors the check doubts, such as someone on a new browser, a shared network or a privacy tool, see a grid of nine pictures under "Select every picture with a bus". The grid usually comes from a CAPTCHA service, drawn in its own frame. Someone who can't tell whether the tram counts, or misses a bus at the edge of a photo, gets a new grid and tries again.
The second is a security photo. When the account was opened, the bank asked people to upload a photo of their own. Now, under "Choose the photo you uploaded", it shows that photo among eight others, and only the right one lets them in. Someone who uploaded it years ago, or who can't remember whether it was the beach or the garden, is stuck.
Either way, the step has only one way through: pick the right pictures. There is no button to email a sign-in link instead, no passkey and nothing else. A screen reader user on the bot check hears "Select every picture with a bus, group", then "Picture 1, checkbox, not checked", and so on to Picture 9, and can't start.
Success criterion 3.3.9, Accessible Authentication (Enhanced), is level AAA and new in WCAG 2.2. No step of signing in may need a cognitive function test, unless the same step offers another way in that needs none, or a mechanism that helps people pass it. It is the same rule as 3.3.8, the AA criterion, with two of its exceptions taken away. At AA, a test of recognising objects, such as picking the buses, and a test of identifying content the person gave the site, such as a photo they uploaded, are allowed. At AAA, neither is. The Understanding document names both pictures here: a step can't show a selection of images where people choose the ones with a given object, or the one they provided.
Nothing in HTML stands in the way: the grid is ordinary images and checkboxes, or a CAPTCHA service's frame, and a page can put either in a sign-in. Alt text doesn't rescue the step either. A bot check's pictures can't be described without telling the bot the answer, and nobody describes a photo someone uploaded, nor the photos beside it; even if they did, the test of recognising a photo would only become a test of remembering a description. Adding an audio version, as some CAPTCHA services do, doesn't count as the other way in: the Understanding document for 3.3.8 says typing what you hear is transcription, which is a test too.
The step comes after the password is right, so it stops people who have done everything else the sign-in asked, often when they most need the account, such as to pay a bill.
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)
- Limited language, cognitive and learning abilities Someone with memory difficulties uploaded a photo when they opened the account, perhaps years ago, and now has to pick it out of nine. People who find pictures hard to read, or who can't decide whether a tram or a coach counts as a bus, get a new grid each time they guess wrong.
- Without vision A screen reader reads the bot check as "Picture 1, checkbox, not checked", nine times: the pictures can't be described without giving the answer away. The uploaded photo and the eight beside it are read only as "Photo 1" to "Photo 9", so a blind user can't tell which is theirs, and there is no other button.
- Limited vision The squares are small, and a bot check's photos are often blurred or cropped. Zooming in makes the squares bigger, not clearer, so a bus at the edge of a photo is easy to miss.
The pictures have alt text, the checkboxes and radio buttons have a group with a legend, and the Continue button has a name, so axe and other scanners pass the step. The step comes after the password, and the bot check shows its pictures only to visitors it doubts, so a scan of the sign-in page sees neither. EaseWeb's audit, which never signs in, lists two things as leads: a picture challenge service, such as reCAPTCHA or hCaptcha, inside a sign-in form; and four or more options that are pictures with no words, under a question about pictures, on a sign-in. A person has to sign in to see whether pictures appear and whether a way in with no test sits beside them. A code assistant asked to protect a sign-in can reach for a picture CAPTCHA or a security photo, and asked to make it accessible, can add an audio version, which leaves the test in place.
Try it
Your password is in. Finish signing in to the bank
Broken 1: pick every picture with a bus, then press Continue. Does the tram count? The panel reads the step from the top, as a screen reader would.
Broken 2: pick the photo you uploaded when you opened the account. Do you know which it was?
Apply a fix. Can you finish signing in without picking a picture?
Broken Can you fix this?
Reading from the top, a screen reader says:
- Signing in as [email protected]
- Select every picture with a bus, group
- Picture 1, checkbox, not checked
- Picture 2, checkbox, not checked
- Picture 3, checkbox, not checked
- …and so on, to Picture 9
- Continue, button
The fix
Let people finish signing in without picking pictures
Every picture with a bus
<form action="/sign-in/check" method="post"> <p>Signing in as [email protected]</p> <fieldset> <legend>Select every picture with a bus</legend> <label> <input type="checkbox" name="picture" value="1"> <img src="/check/1.jpg" alt="Picture 1"> </label> … </fieldset> <button type="submit">Continue</button></form>What is wrong3 points
The … stands for the other eight pictures, each the same as the first. The markup is what a CAPTCHA service's grid amounts to, whether it is drawn in the page or in the service's frame.
- The only way on is to recognise the buses among the pictures.
- The alt text can't say what each picture shows without giving the answer away.
- Nothing in the step offers another way in.
An emailed sign-in link in place of the pictures
<form action="/sign-in/email-link" method="post"> <p>Signing in as [email protected]</p> <button type="submit">Email me a sign-in link</button></form>How it is fixed3 steps
- Take out the pictures and their question. There is nothing left to recognise or remember.
- Send the form to an address where the server emails a link to the account's own address, and the link finishes signing in (technique G218).
- Name the button for what it does: "Email me a sign-in link".
This fixes both Befores and passes 3.3.9. It asks people to reach their email and open the link before it expires, so say on the next page where the link went and how long it works.
Both pass 3.3.9, and both take the test away for everyone rather than adding a way round it. Use the emailed link alone when the site has no passkeys yet: it is one form and one button, with nothing new to build on the page. Add the passkey when the site supports them: people who have one finish in a single step without leaving the page, and the emailed link still covers everyone else. Where the picture step can't change, such as a CAPTCHA service a policy requires, putting the emailed link beside the pictures also passes, since 3.3.9 allows a test that has another way in beside it; the guide on CAPTCHAs shows that pattern.
If the pictures were only there to stop programs that try password after password, the step can go without a replacement: limits on attempts per account and per address do that job on the server, with no test for the person, as CAPTCHAs with no way past them except solving the puzzle explains.
A security picture that the bank only shows, for people to check before they type their password, asks nothing that the sign-in checks, so it isn't the test this criterion is about. It doesn't do much either: in a 2007 study of bank customers, 23 of the 25 who used their own accounts typed their password even when the picture was gone. Picking an uploaded photo out of several is the step 3.3.9 rules out, and the Understanding document for 3.3.8 warns that such personal content can be guessed: one in nine, here. A picture people chose from the bank's own set, rather than uploaded, fails sooner: 3.3.8's exception covers only content the person provided, so picking it out already fails 3.3.8 at AA, the criterion behind password fields that won't take a pasted password.
Make the emailed link work once and for a short time, and say both on the page that tells people it was sent. A code sent by text message is another second step, but typing it is transcription; it needs the paste and autofill that one-time code boxes that won't take a pasted code covers.
Offer a passkey beside other ways in, never as the only one. Some people can't use a fingerprint or a face, and EN 301 549 clause 5.3 asks that no single biological characteristic be the only way to identify a user; a device's screen lock PIN works for passkeys too. Asking people to make a passkey once they are signed in, rather than in the middle of signing in, keeps the sign-in itself short.
The rest of signing in needs the same care: a password field that refuses a paste fails 3.3.8; see password fields that won't take a pasted password.
Verify the fix
3 checks, no mouse.
Test with: Screen reader, Keyboard
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the sign-in, its bot check or its second step changes.
Limits
This is a starting pattern, not a guarantee for every sign-in. 3.3.9 is level AAA, which most laws and policies don't require, but the people it protects are the same people a sign-in at AA still shuts out with pictures. It covers signing in, not creating an account or recovering one, though a picture step there stops the same people. An emailed link helps only people who can reach their email, and a passkey only people who have one, so keep more than one way in. Test the whole sign-in, including what appears only to visitors a bot check doubts, 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
- WCAG Understanding: accessible-authentication-enhanced (opens in a new tab)
- WCAG Understanding: accessible-authentication-minimum (opens in a new tab)
- WCAG Technique G218 (opens in a new tab)
- w3.org: turingtest (opens in a new tab)
- developer.mozilla.org: Web_Authentication_API (opens in a new tab)
- developer.mozilla.org: parseRequestOptionsFromJSON_static (opens in a new tab)
- cl.cam.ac.uk: emperor.pdf (opens in a new tab)
EaseWeb service
Fixed it? Keep it from coming back.
I turn guides like this one into rules your coding agents follow and checks your CI runs. Then I retest by hand with a keyboard and screen readers, periodically.