CAPTCHA and accessibility
CAPTCHAs are often used as a website’s first defence against computer bots submitting forms, such as login, email or comment forms. All CAPTCHAs have usability issues and many have significant accessibility barriers. Government organisations are encouraged to avoid them and instead implement a number of alternative techniques to prevent or reduce access by bots.
See the latest guidance on CAPTCHA
This page is currently out of date — for the latest guidance on this topic, see CAPTCHA — Web Accessibility Guide — NZ Government.
What is CAPTCHA
CAPTCHA stands for Completely Automated Public Turing test to tell Computers and Humans Apart.
A CAPTCHA might take the form of an image presenting a word or string of characters that is difficult to decipher. It might also be a simple logic-based or mathematical question, for example ‘Is ice hot or cold?’ or ‘What is 2 + 3?’
The purpose is to provide a challenge to the user that a human can solve but a computer bot can’t.
There are a number of types of CAPTCHA, but image CAPTCHAs seem to be the most prevalent. Also, as computer bots get more sophisticated, CAPTCHAs are getting more and more complex or difficult to decipher, even for human users.
Accessibility concerns
All CAPTCHAs introduce some kind of usability hurdle, but in many instances they also present significant accessibility barriers.
Most CAPTCHAs, including those that use more than one modality (for example, an image CAPTCHA for the sighted and an audio CAPTCHA for the vision impaired), block access to 1 or more type of user. For example, version 2 of the popular reCAPTCHA service checks a user's behaviour and, if it's suspect, presents the user with an image challenge, along with an alternative audio challenge for the vision-imapired. However, this still blocks access to people who are deaf-blind.
The more recent version 3 of reCAPTCHA returns a score based on the user's interaction with the site. A low score indicates a likely bot, at which point the site owner can decide how to respond. For instance, the site might ask the user to perform 2-factor authentication or email verification, 2 methods that can be made 100% accessible to all users.
If a test that requires user interaction is deemed necessary, it's suggested that this be something no more complicated than directing the user to enter a specific, randomly generated string into a text input, such as “Enter ‘syi339’”, or possibly very simple math questions, such as ‘What is 2+3?’
However, keep in mind that logic or language questions may be extremely difficult for some users with cognitive impairments, learning difficulties or English as a second language. If such an approach is taken, it can be combined with other non-CAPTCHA approaches as described below.
WCAG 2.1 on image-based CAPTCHAs
If an image CAPTCHA is used, follow the Web Content Accessibility Guidelines (WCAG) 2.1 guidance on image CAPTCHAs:
CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
For help with this, see the following WCAG 2.1 techniques regarding the use of CAPTCHA:
Avoid using CAPTCHAs
Given the accessibility issues with CAPTCHAs, Government organisations are encouraged to avoid them where possible and instead implement a number of alternative techniques to prevent or reduce access by bots.
Alternative techniques
There are a number of ways to prevent or reduce the submission of forms by bots.
Honeypot
An additional form field is included following the form’s submit button. The form field does not use the type="hidden" attribute and value, but is hidden using CSS display:none. This prevents screen readers from reading the field. Regardless, to be safe, the form field should also have a descriptive label that is similarly hidden, but clearly indicates to screen reader users that they should not enter anything in the field.
Upon submission of the form, the field is checked for content, and if it contains a value, the form submission is considered invalid.
Checking form submission time
Script the page the form is on in such a way to monitor how long it took the user to submit the form. If the form is submitted too quickly (for example, within a few seconds) or too slowly (for example, after 45 minutes), it was most likely completed by a bot.
Spam-free accessible forms — WebAIM
Other approaches
For other approaches, see:
Utility links and page information
Last updated
