CAPTCHA technologies are commonplace on the internet. Per Built With, over 20 percent of the top 1 million websites use some form of CAPTCHA, with the vast majority of sites preferring Google’s reCAPTCHA technology.
Unfortunately, some sites use outdated CAPTCHA technologies that create accessibility issues. To understand why — and to avoid poor CAPTCHA implementation — it’s helpful to consider the problems that challenge-response tests attempt to address.
CAPTCHA is an acronym for Completely Automated Public Turing test to tell Computers and Humans Apart (Wikipedia describes the acronym as “contrived,” and we tend to agree). First invented in 1997, CAPTCHA requires the user to interpret a series of letters and numbers in a distorted image. The purpose is to prevent computer programs from interacting with a site. This can be beneficial in many circumstances; on an e-commerce website, for instance, CAPTCHAs could prevent fraud or stop scalpers from placing automatic orders.
Of course, CAPTCHAs are controversial with real-world web users. Some important points to keep in mind:
- Visual CAPTCHAs present significant problems for people with vision-related disabilities. CAPTCHAs cannot have a text alternative — that would prevent the test from doing its job.
- Audio CAPTCHAs are not an effective alternative. Audio CAPTCHAs cannot have alt-text either, and some users have both vision and hearing disabilities.
- Visual CAPTCHAS create frustrations for all users. Even if you’re able to process visual and audio information, CAPTCHAs might present information that could be interpreted in several ways.
- When users are frustrated by CAPTCHA, they’re less likely to continue using a site. In one large-scale usability test, Baymard Institute found that 8.66 percent of users mistype their first CAPTCHA attempt. That number increased to 29.45 percent when the CAPTCHA was case-sensitive.
An incorrect entry can be discouraging. If you’ve tried to purchase something only to leave checkout after struggling with confusing image-based CAPTCHAs, you’ve experienced this issue.
Still, many sites (particularly e-commerce sites) cling to outdated CAPTCHA tools. Many of these sites prioritize accessibility in other ways — but a single major issue can have a dramatic effect on real-world users. Poor CAPTCHA implementation certainly qualifies.
Are CAPTCHAs Allowed Under WCAG?
Visual Turing tests like CAPTCHA are allowed under the Web Content Accessibility Guidelines (WCAG) with some significant caveats. First, sites that use CAPTCHAS must offer alternatives “using output modes for different types of sensory perception" to accommodate different disabilities. WCAG also requires text alternatives that identify and describe the purpose of the non-text content (such as the text describing the CAPTCHA challenge).
Crucially, the exemption for CAPTCHAs only applies to the generated CAPTCHA content — the images or numbers that users are expected to interpret. All other content must have text alternatives. Many webmasters ignore this distinction and assume that entire pages are exempt.
In other words, the guidelines allow CAPTCHAs, but websites must use them carefully and avoid shutting out human users with disabilities. Wherever possible, webmasters should avoid using image-based CAPTCHA tests, which can create more problems than they solve.
Fortunately, technology has progressed significantly over the past three decades. Many modern tests resolve most of legacy CAPTCHA’s major issues, though webmasters must still use them thoughtfully.
Accessible Alternatives to CAPTCHA
As we’ve discussed, CAPTCHA can be frustrating even when users have access to alternative output modes. For instance, audio CAPTCHA needs to be complex in order to prevent spam. An audio CAPTCHA may contain distortion, strange vocal tones, and other artifacts that can be distressing to users — and annoying, since the same artifacts that prevent bot traffic can also prevent human users from accessing the site.
Google’s reCAPTCHA v2 attempts to solve these problems by presenting users with a simple “I’m not a robot" checkbox. The user clicks the box to access the site. reCAPTCHA fields can be interpreted by major screen readers (assistive technologies that convert visual content to audio or braille output). The box also is accessible via keyboard, which is helpful to people with certain mobility and cognitive disabilities.
To confirm the user’s humanity, Google uses an algorithm to determine if the movements are natural. The algorithm also attempts to analyze the user’s IP address, the number of requests sent within a certain time frame, and other information. If the algorithm isn’t satisfied, the user may still see a traditional CAPTCHA box, but this is extremely unlikely for screen reader users.
Alternatively, web designers can employ reCAPTCHA v2’s invisible badge, which invokes the reCAPTCHA verification when a user clicks an existing button on the site. Google’s reCAPTCHA v3 works similarly by verifying legitimate interactions with a pure Javascript API — the user never notices the reCAPTCHA field.
Other CAPTCHA alternatives use other parameters to assess users without presenting them with annoying form entries. hCaptcha, the most popular reCAPTCHA alternative, uses machine learning models to detect human users. People with disabilities must sign up with the hCaptcha accessibility sign-up page. They receive an encrypted cookie that must be refreshed every 24 hours.
That cookie can be used several times per day, and the signup process is straightforward. However, hCaptcha Accessibility Access requires an email address, and some users may prefer not to provide this information.
Make CAPTCHA Accessibility to Everyone
Regardless of which CAPTCHA technology you deploy on your site, remember: No tool is automatically accessible, and by nature, CAPTCHAs are designed to create accessibility issues. Even with newer technologies, CAPTCHAs can be risky.
To keep your site accessible — and avoid locking out millions of potential users — you’ll need to look closely at how you implement your security features. Here are a few considerations to keep in mind.
Avoid requiring proof-of-humanity without a good reason.
First, determine whether a CAPTCHA is actually necessary. This may sound like an obvious step, but many sites use Turing tests without a good reason.
If you’re operating a large e-commerce site, you have a legitimate reason to try to limit spam traffic, and reCAPTCHA or hCaptcha might be the only solution. If you’re maintaining a small company website, however, you might not need CAPTCHA to prevent bots from overrunning your servers — you could use filters and bot mitigation tools to accomplish the same effect. Before using any form of CAPTCHA, look for user-friendly alternatives.
Recognize the full spectrum of disabilities.
Classic CAPTCHAs use image-based testing, which presents a clear challenge to people who have vision issues. If you’re reading this article, you’ve probably considered how visual media affects these users (and you’re not alone — as we noted in this piece, the idea that accessibility means “designing for people who are blind" is one of the most common myths of website accessibility).
A truly accessible mindset doesn’t stop there. Remember, certain types of testing can also present issues for people who use keyboards to operate their web browsers. A person with an anxiety disorder may feel overwhelmed by an incorrect CAPTCHA entry, and a person with short-term memory issues may not be able to follow a complex CAPTCHA with multiple steps.
To address the needs of all of your users, think about how your test operates. Consider whether any aspect of the test would create an unnecessary burden, then attempt to address those concerns before they affect real-world users.
Avoid time-gated CAPTCHAs.
Be aware of timeout limits. Time limits can be frustrating for all users, and some people may not be able to complete CAPTCHAs within a short time frame. Make sure CAPTCHA fields are located at the ends of forms.
Of course, the simplest way to prevent this issue is to use a CAPTCHA technology that doesn’t have a short time limit, or to use a test that doesn’t require the user’s direct interaction.
Don’t neglect other accessibility issues.
Remember, your responsibility doesn’t end after you’ve chosen a relatively accessible CAPTCHA technology. For instance, many websites use CAPTCHAs to prevent spam form submissions. If the form has a time limit, adding the CAPTCHA could cause some users to exceed that time limit — WCAG 2.1 Success Criterion 2.2.1 recommends allowing users to turn off, adjust, or extend time limits with simple actions, which would resolve the issue.
Similarly, your forms should avoid using auto-advance, which creates serious hurdles for some people with disabilities. All input elements should be clearly and explicitly labeled (we covered some of the features of accessible forms in the article linked here).
Ultimately, CAPTCHA-type technologies can be useful, provided that you utilize them carefully and prioritize accessibility throughout your site. However, CAPTCHA technologies change frequently, and before implementing any new security controls, you’ll need to plan carefully.
