CAPTCHA and accessibility

CAPTCHA (which stands for “Completely Automated Public Turing test to tell Computers and Humans Apart”) are often used as a website’s first defence against the submitting of forms, e.g. login, email, or comment forms, by computer bots.

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, e.g. “Is ice hot or cold?” or “What is 2 + 3?”. The purpose, of course, is 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 do 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.

CAPTCHA from the source

As general guidance, see CAPTCHA: Telling Humans and Computers Apart Automatically, from Carnegie Mellon University, which invented the CAPTCHA for Yahoo!. An abbreviated version of their guidelines follows.

If your website needs protection from abuse, it is recommended that you use a CAPTCHA. There are many CAPTCHA implementations, some better than others. The following guidelines are strongly recommended for any CAPTCHA code:

  • Accessibility. CAPTCHAs must be accessible. CAPTCHAs based solely on reading text — or other visual-perception tasks — prevent visually impaired users from accessing the protected resource.…
  • Image Security. CAPTCHA images of text should be distorted randomly before being presented to the user.…
  • Script Security. Building a secure CAPTCHA code is not easy. In addition to making the images unreadable by computers, the system should ensure that there are no easy ways around it at the script level.…
  • Security Even After Wide-Spread Adoption. There are various “CAPTCHAs” that would be insecure if a significant number of sites started using them. An example of such a puzzle is asking text-based questions, such as a mathematical question (“what is 1+1”).…
  • Should I Make My Own CAPTCHA? In general, making your own CAPTCHA script (e.g., using PHP, Perl or .Net) is a bad idea, as there are many failure modes. We recommend that you use a well-tested implementation such as reCAPTCHA.

Accessibility concerns

All CAPTCHAs introduce some kind of usability hurdle, but in most instances they also present significant accessibility barriers.

Most CAPTCHAs, including those that use more than one modality (e.g. an image CAPTCHA for the sighted and an audio CAPTCHA for the vision impaired), block access to one or more type of user. For example, the popular image-based reCaptcha service, which offers an audio alternative, still blocks access to people who are Deaf-blind.

If a test that requires user interaction is deemed necessary, it is suggested that this be something no more complicated than directing the user to enter a specific, randomly generated string into a text input, e.g. “Enter ‘syi339’”, or possibly very simple math questions, e.g. “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 those for whom English is a second language. If such an approach is taken, it can be combined with other non-CAPTCHA approaches as described below.

WCAG 2.0 on image-based CAPTCHAs

If an image CAPTCHA is used, it is important that the Web Content Accessibility Guidelines (WCAG) 2.0 guidance on image CAPTCHAs is followed:

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 WCAG 2.0 technique G143 and technique G144 regarding the use of CAPTCHA.

Avoid using CAPTCHAs

Given the accessibility issues with CAPTCHAs, Government organisations are encouraged to avoid them 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 it is hidden using CSS display:none. This will prevent 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 (e.g. within a few seconds) or too slowly (e.g. after 45mins), it was most likely completed by a bot. This approach is described in the WebAIM article, Spam-free accessible forms.

Other approaches

For other approaches, see: