Most of us know CAPTCHA tests as the interactive challenges we have to do to prove we are in fact humans and not robots.
For example, the hard-to-read text we have to decipher before submitting a form, or challenges where you select the images with a car.
Perhaps the most familiar CAPTCHA is Google’s “No CAPTCHA reCAPTCHA”, which is an (almost) non-interactive CAPTCHA test. (We’ll get into this more below).
These tests serve an important purpose in attempting to secure websites from unwanted bots, but they also can prevent users with disabilities from creating accounts, making purchases, or other secure interactions.
There are options that can keep your website secure while also keeping it accessible.
In this article, we’ll go over:
- What is CAPTCHA?
- What is Google’s reCAPTCHA?
- How interactive CAPTCHA options affect users with disabilities
- Interactive CAPTCHA tests’ security effectiveness
- Choosing an alternative to interactive CAPTCHA challenges
What is CAPTCHA?
CAPTCHA stands for Completely Automated Public Turing-test to tell Computers and Humans Apart – we’ll stick to the much more succinct CAPTCHA.
In this article, we’ll use the term CAPTCHA to refer to any technique used to test if someone is a human or a robot.
There are interactive and non-interactive CAPTCHA tests. For example, the CAPTCHAs we are most familiar with are interactive CAPTCHA tests. They are visual or audio challenges we have to pass to prove we are human.
But, there are also non-interactive CAPTCHA tests, which have a lot of accessibility benefits. We’ll dig into these more in Choosing an alternative to interactive CAPTCHA tests.
What is Google’s reCAPTCHA?
This wouldn’t be an article on CAPTCHA accessibility without going over the most popular CAPTCHA tests there are – Google’s reCAPTCHA.
Google’s reCAPTCHA V2
Google’s reCAPTCHA Enterprise has two options. One is the “No CAPTCHA reCAPTCHA”, or their reCAPTCHA V2.
Here’s how it works: a user gets the option to select the “I’m not a robot” checkmark, and as soon as they do, Google uses their information to determine if they are a robot or not.
If it determines they aren’t a robot, they get a green checkmark – woo! If there’s any question, the user gets an interactive CAPTCHA challenge.
This is why it’s mostly non-interactive. If a user with a disability passes the initial checkbox, they don’t have an issue. But, if they don’t, they have to pass an interactive CAPTCHA challenge, which can block them from completing their task.
Plus, users using a keyboard or screen reader are more likely to not pass the initial non-interactive checkbox because of the way they navigate the web.
Google’s reCAPTCHA V3
Google’s reCAPTCHA V3 is score-based and takes out the mostly in mostly non-interactive. It collects information on the user based on how they interact with your site, and creates a score. The organization can decide what a low score is and how to treat it. For example, sending the comment to moderation or additional authentication through email.
This non-interactive approach can be accessible even if the score is low depending on how the organization chooses to handle a low score.
CAPTCHA’s impact on users with disabilities
Now that you know more about interactive and non-interactive CAPTCHA options, let’s review the accessibility of interactive CAPTCHA challenges.
In WebAIM’s 2017 Screen reader user survey (the last time the problematic items question was asked), CAPTCHAs were by far the most problematic item for screen reader users.
Google’s own reCAPTCHA documentation says interactive “CAPTCHA [challenges] are not accessible for all users, so they might not be suitable if your website has accessibility requirements,” and suggests their new, score-based CAPTCHA for websites with accessibility requirements.
Interactive CAPTCHA challenges could fail several of WCAG’s 2.1 success criteria. But, WCAG 2.2, which is still in the editor’s draft process, introduces the first success criterion to explicitly mention authentication.
The new criterion is 3.3.7: Accessible Authentication (AA). This criterion states:
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:
- 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.
Basically, all interactive CAPTCHAs could fall under a cognitive function test, but CAPTCHA challenges like Google’s “select the part of the image with a car” are an exception because it is a cognitive function test to recognize objects.
And, only having interactive CAPTCHAs like deciphering the word or solving a logic problem would fail Level AA – there would need to be an alternative option.
This new criteria is evidence that CAPTCHA accessibility is an issue. So, here are some examples to demonstrate how interactive CAPTCHA challenges can be a frustrating, and even an impassable barrier.
Visual CAPTCHAs
Visual, interactive CAPTCHAs like typing the letters or selecting the part of the image with the car are only solvable for visual users.
Users with cognitive disabilities could also have difficulty with visual challenges like deciphering the distorted text and then transcribing it into the text box. Or, even, selecting the right part of the image.
Remember, both of these would now be considered cognitive tests. But, recognizing objects is still acceptable under Level AA.
To top it off, these visual challenges are very cultural, meaning they use a specific language or reference images of things people in other cultures might not be familiar with. This can also make it difficult to solve.
Audio CAPTCHAs
Now, if the user has a visual disability, or wasn’t able to solve the visual challenge, they can often opt for an audio challenge. (This alternative output type is required under the success criterion 1.1.1 Non-Text Content).
If you’ve never heard what an audio CAPTCHA sounds like, you can listen to the one below.
Basically, there is static to distort the sound. Then, the user has to type what they hear. Typing the audio is what makes this a cognitive test.
Similar to the distorted text, the audio can be difficult to understand. It can also have cultural implications due to the accent or even the words being spoken.
Take the example above, it’s saying “open Wimbledon.” Wimbledon is a tennis championship and might not be a familiar word to everyone. I listened to it several times and did not feel confident when I typed in open Wimbledon.
If someone isn’t able to pass the visual challenge, plus is having a difficult time with the audio challenge, they come to an impassable barrier to creating an account, submitting a form, or another interaction.
Logic CAPTCHAs
There is another type of interactive CAPTCHA – logic challenges. These could be a math equation or word puzzle asking them to select a certain word on the list.
A visual user could read this and solve it, and a user who has a screen reader could have the screen reader read the challenge to them and then solve it.
But, this type of challenge could be impassable for someone with a cognitive disability and only having this type of cognitive test would fail draft success criterion 3.3.7: Accessible Authentication (AA).
All of these interactive CAPTCHA challenges put the burden to prove people aren’t a robot on the user and can be difficult for everyone. But, they can be impassible barriers for users with disabilities preventing them from full access, which is a problem.
Interactive CAPTCHA tests’ security effectiveness
Not only are interactive CAPTCHA tests inaccessible, but they also aren’t as secure as they used to be.
Computer algorithms are now able to solve distorted text, logic problems, or audio CAPTCHAs. In fact, they are often better at solving certain CAPTCHA than people.
W3C’s Inaccessibility of CAPTCHA’s Group Draft Note says:
“Current CAPTCHA methods that rely primarily on traditional image-based approaches, logic problems, or audio CAPTCHA alternatives can be largely cracked using both complex and simple computer algorithms.”
Even Google’s caveat’s to CAPTCHA challenges warns that CAPTCHAs aren’t as reliable at determining between humans and bots and that there are paid attackers who can get past any CAPTCHA challenge.
To help get around bots getting smarter, interactive text and audio CAPTCHAs have gotten more distorted making them even harder for people to solve.
Even without bots and paid attackers challenging interactive CAPTCHA tests’ security, they still aren’t secure because they aren’t accessible.
Consider this: the key points of security are C.I.A., which stands for Confidentiality, Integrity, and Availability.
If someone needs help to login, it isn’t confidential. Even if someone just needs help with the CAPTCHA challenge, it isn’t confidential because information could be seen after logging in.
Next, if someone could change information without the person who needs help knowing, they are helping them lose integrity.
Lastly, if a user is blocked because they failed the CAPTCHA challenge, they’ve lost availability.
So, even if interactive CAPTCHAs were secure against bots and paid attackers, we’ve still lost security because they aren’t accessible.
Choosing an alternative to interactive CAPTCHA challenges
This means an interactive CAPTCHA challenge isn’t your one-stop solution to security or accessibility. There are other options, but how do you pick one, or a combination of them?
Choosing a security method
Choosing an alternative security method all starts with the business use case. This means defining why you are using the CAPTCHA challenge or want the added security. For example, some use cases are:
- We are getting too much spam in our contact form, so we are missing real people’s submissions.
- We are getting spam in our comments, which makes us look unprofessional.
- We want to make sure people signing up for our event are real people.
- We only want real people signing up for our newsletter.
- We have sensitive information and need to block targeted attacks.
Unless you know you need a complex security solution to protect an application or against targeted attacks, it’s best to start simple.
For example, with a contact form, event sign-up, or comments, are you even getting spam? If the answer is yes, again, keep the solution simple, like a simple honeypot. Then, see if that works for you. You can make more complex solutions or even combine methods depending on your use case.
Whatever method you pick, try and keep the burden off the user if possible. For example, several of the solutions below, like heuristics and honey pots, don’t require the user to do anything. But, solutions like an interactive CAPTCHA challenge or multi-factor authentication do require the user to take action.
Heuristics
Google’s reCAPTCHA V3 is an example of using heuristics, or a user’s data, to guess if the user is a human or bot based on a score. It is then up to the application to decide what to do with that score.
An accessible option could be to keep the score higher, and then if triggered, do email verification or send the comment to moderation.
Heuristics can be accessible and secure, especially when paired with another accessible option.
Honeypots
Honeypots can be simple or complex. An example of a simple honeypot would be adding a hidden form field just for bots. If it’s filled in, the form errors out and won’t be submitted.
For example, in the screenshot below, the last field is a honeypot. This field is typically hidden from visual and screen reader users using CSS.
We’ve found this very effective at blocking spam from coming into contact or create account forms.
A more complex honeypot would be to create a fake location on your server with fake data for hackers to think they found a vulnerability. These require a lot more resources but are more secure for sensitive data or large organizations that are being targeted.
Email, text, or phone verification (multi-factor authentication)
Email, text, or phone verification means the user confirms they are a human and their identity by sending an email or code to their phone.
This can be effective for logging in, user sign-ups for an account, or newsletter sign-ups and is more secure than adding a hidden form field. But, it does put the burden back on the user. Keep in mind, an MFA method would still need to be accessible itself.
As we mentioned before, this can be combined with heuristics, or even used alone if extra security is needed.
Server-side blocking
If you’re 100% sure it’s a bot, you could block their IP address. For example, if a comment is sent to moderation, and it’s spam, block that IP address.
There are some catches though: unless you are 100% sure it’s a bot, blocking a user would prevent them from completing the interaction. For example, if you block a user just because they had a low heuristic score. In that case, providing an accessible fallback instead of blocking them would let them prove they are human and complete their interaction.
Plus, blocking an IP address might also inadvertently block an entire organization or a different user who has that IP in the future.
Server-side blocking can be combined with a honeypot and other heuristic data like time to complete the form or a spam word list to block most spam for a typical form.
These alternative options to interactive CAPTCHA challenges can make your website secure and accessible. Just remember, define your business case, start simple, and work with your organization’s cybersecurity expert to find the right accessible option or combination of options for you.