Completely Automated Public Turing test to tell Computers and Humans Apart (shortened to CAPTCHA) is often a time consuming barrier for multiple groups of people. People not able to see the screen can’t really submit the form if CAPTCHA isn’t accessible (most CAPTCHAs are often very visual, using images or images of skewed text that need to be perceived and then typed into a text field, for example).
No wonder that even after 14 years of WebAIM’s Screen Reader survey, CAPTCHA is the most problematic item on the web (opens in new window) for screen reader users. Imagine filling out a complex form just to find out that it has a CAPTCHA at the end, and an inaccessible one. That often means you have to reach out for help and by doing that you need to give up your privacy. And if you have to wait for help for more than 20 minutes (quite common session timeout default) you also risk the requirement to repeat filling out the form in the first place. And not to mention that if form is not coded properly (unfortunately a lot of forms are not) you also risk that your autocomplete will not make it easier for you to fill out the form.
I often see people struggle with forms, and I often struggle with CAPTCHAs, even if I can see the skewed text, but it is way worse for people depending on screen-readers (also people with vision impairments and people with cognitive disabilities).
Are there any accessible CAPTCHA solutions?
In the recent years we got some alternatives, but if CAPTCHA only offers two modalities it can still be inaccessible. Visual and audio captcha can still not be enough for some people, as we really need text only CAPTCHA as well. So if you think that adding an audio CAPTCHA will make things totally accessible – you might be wrong – depending on the visual CAPTCHA. Adding alternative texts to strange fonts goes against the purpose to stop bots, so you need to have totally other concept of text only CAPTCHA, like for example solving a simple riddle or mathematical equation (like for example how much is 7 and 3).
Additional perspective – solutions that offer the best possible (and most accessible) CAPTCHAs are often third party scripts that may not be viable for some websites (or apps), and are often left out in favor of first-party CAPTCHA solutions that are likely outdated and less accessible.
There are also technical solutions that don’t require third parties and any CAPTCHAs at all, so called honeypots where we extend original form with visually hidden form fields that are often filled out by automatic scripts trying to spam our form and by checking those fields we know that something was populated automatically. Such trivial solutions can often work, at least until bad actors check the form manually.
Conclusion – test before using
I suggest dropping visual CAPTCHAs (even if they offer some audio mode) and trying with honeypot first. After some time we can then check and if spam still comes through I suggest using simple CAPTCHA in text form (like for example a simple mathematical equation on top of honeypot). If that still doesn’t help we can look into third parties (provided our security and performance policies allow that) or investigating other possibilities (perhaps improving heuristics for bot detection with the help of spam email address and word checking).
In any case – please make sure to consider WCAG and test with different users!
Additional resources
- W3C Group Draft – Inaccessibility of CAPTCHA Alternatives to Visual Turing Tests on the Web (opens in new window).
- WCAG 2.2 Success Criterion 3.3.8 Accessible Authentication (Minimum, opens in new window).
- WCAG Technique G144: Ensuring that the Web Page contains another CAPTCHA serving the same purpose using a different modality (opens in new window).
- Deque University – Accessibility Techniques for CAPTCHA (opens in new window).
