CAPTCHA: accessibility for developers

  • Author: Access iQ ®
  • Date: 1 Feb 2013
  • Access: Premium

Quick facts

A well-known method of preventing unwanted form submissions is to use a CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) in order to avoid input that has been generated by a computer or "bots".

  • Before implementation, consider whether a CAPTCHA is necessary and if an alternative is available.
  • Research options before choosing a solution.
  • Look at different types of CATPCHAs: reCAPTCHA, Text-only CAPTCHAs, Honeypot CAPTCHAs.

On many websites, it is common to ask visitors to supply information or content via a web form. These forms are vulnerable because they present an opportunity for bots to automatically fill in and submit forms. These spam submissions can vary from relatively benign skewing of opinion polls or placing advertising into comments to more damaging vandalism, spreading malicious code or stealing private information.

A well-known method of preventing unwanted form submissions is to a CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) in order to avoid input that has been generated by a computer or "bots". CAPTCHAs do this by giving a user some sort of challenge that would be difficult for an automated bot to complete successfully.

The most common form of CAPTCHA is illustrated below, where distorted text is presented as an image. The user is expected to type the characters they see into a form field. The assumption is that most bots are not capable of recognising or interpreting the distorted text and will fail the CAPTCHA.

People with an impairment or disability may not be able to pass this sort of CAPTCHA.

A CAPTCHA using a single word verification with distorted text presented as an image.

People with an impairment or disability may not be able to pass this sort of CAPTCHA.

This includes people who:

  • are blind
  • are vision impaired
  • are dyslexic
  • have difficulty reading

The difficulty in making a CAPTCHA image accessible is that providing a text alternative of the image, as required for screen reader users to understand the content, also supplies the answer to the bot.

Success Criterion 1.1.1 Non-text content explicitly excludes the requirement to supply a text alternative to a CAPTCHA image for this very reason. But that doesn't let the developer off the hook, because it required that:

…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.

This can be satisfied by providing a text alternative that identifies the purpose of the CAPTCHA, and ensuring the page provides another CAPTCHA that serves the same purpose but is perceivable by a different sense. For example, by presenting a test that depends on hearing, not sight. It should be noted that the audio test does not have to replicate the visual test verbatim, it merely needs to have the same amount of distortion to the test.

Do you really need a CAPTCHA?

Before implementing a CAPTCHA, consider if it really is a necessity and whether an alternative is available.

The W3C's Understanding Success Criterion 1.1.1 Non-text content states:

Every type of CAPTCHA will be unsolvable by users with certain disabilities. However, they are widely used, and the WCAG Working Group believes that if CAPTCHAs were forbidden outright, websites would choose not to conform to WCAG rather than abandon CAPTCHA. This would create barriers for a great many more users with disabilities.

This statement acknowledges that CAPTCHAs will never be accessible to all users. In fact, it could be argued that CAPTCHAs are difficult for all users to solve. As spambots become more sophisticated, the algorithms used to stop them distort letters more and more. There are times where it is necessary for users to refresh an image-only CAPTCHA because the letters are too distorted to solve the CAPTCHA.

Spambots also target audio CAPTCHAs, making it necessary for ‘audio distortion’ to be added to the audio file which reads out the letters for an audio CAPTCHA. Some audio CAPTCHAs are so noisy it is almost impossible to solve them correctly.

For all users, it may be that a viable solution is to not use a CAPTCHA application programming interface (API) for your forms, since making it accessible to all users irrespective of ability may be prohibitive or impossible.

There are techniques, as discussed in the W3C paper: Inaccessibility of CAPTCHA: Alternatives to Visual Turing Tests on the Web that can be used instead, which can be just as effective. Using a CAPTCHA offloads security onto your site's users, rather than exploring better ways to manage your security. A good developer may discover several ways that do not require extra attention by the user. For example:

  • If using a CAPTCHA to restrict the amount of searches for concert tickets on your site, consider instead limiting the user to a few searches per day.
  • If a form is filled out significantly more quickly than the speed of an average person typing, it may be acceptable to assume the submission is not being made by a human.

Research before choosing a solution

Before implementing a CAPTCHA, the website owner should clearly specify the type of input they want to receive, and the developer should implement a useful, accessible and proportionate solution.

A common solution is to use a plugin, widget, or externally supplied code via an API or built into a content management system (CMS). These add-ons remove the need to build a bespoke solution, but very few satisfy either the WCAG 2.0 success criteria or the range of disabilities users may have. For example, one very popular CAPTCHA has an extremely noisy audio version that is not a viable alternative form of CAPTCHA because it is difficult to perceive the content delivered.

Any CAPTCHA implementation should be tested against a range of disabilities, instead of accepting the vendor or distributor's claim that it is accessible. Some CAPTCHA APIs that claim accessibility is difficult to use in the audio modality, have small buttons, or are not keyboard-navigable.

Consider implementing a fallback for any CAPTCHA that requires connecting to an external supply of resources as part of the test, since a loss of that feed will prevent the form being submitted. It is a much better practice to present a static test in order to capture and quarantine important inputs, than to have a broken form that the user cannot move through and will be reluctant to return to.


Arguably the most common CAPTCHA is that available from the official CAPTCHA site, where it is actively maintained and versions are available as plugins to popular applications and programming languages including WordPress, Drupal, Joomla, PHP and Ruby.

The reCAPTCHA interface displaying two distorted words, a text entry field, and three buttons to get a new CAPTCHA, play an audio CAPTCHA, and to get help.

Although reCAPTCHA provides an audio CAPTCHA for people for who are blind and vision impaired, other accessibility requirements must also be considered. These include keyboard accessibility and visible focus.

reCAPTCHA does not meet Success Criterion 2.4.7 Focus visible and the way it is set out, using tables for layout, may negatively impact the usability for screen reader users.

Text-only CAPTCHAs

Some CAPTCHAs don't rely on an image at all, but present the user with a text question to answer, such as textCAPTCHA. These assume that the logic required to answer the question correctly is beyond the scope of a machine. For example:

  • The list green, lion, butter and house contains how many colours?
  • What is seventy thousand eight hundred and forty eight as a digit?
  • Which of cheese, school, Friday, underpants or knee is a day of the week?

The advantage of text-only CAPTCHAs compared with image-based CAPTCHAs from an accessibility point of view is that the questions are text and thus easily accessible to assistive technology users such as screen reader and Braille device users.

However, because text-only CAPTCHAs rely on a certain level of cognitive ability, they may be inaccessible to people with learning disabilities such as dyslexia and dyscalculia, or intellectual disabilities and cognitive limitations. Text-only CAPTCHAs could be used as a fallback to image-based CAPTCHAs which would cater to both people who are vision impaired and with cognitive limitations.

Although text-only CAPTCHAs are not as secure as image-only CAPTCHAs, they can be completed with server-side functions for added security.

Honeypot CAPTCHAs

Honeypot CAPTCHAs remain an effective method for thwarting SPAMbots while being completely unobtrusive to users, by:

  • creating an extra input field for your form
  • making it attractive to SPAMbots with a name attribute like "name" or "email"
  • hiding it from users and assistive technologies with cascading style sheets (CSS)
  • requiring the form to ignore or quarantine submissions with the field filled in

It is best to return no error to the browser to prevent the SPAMbot from learning from its mistake. This requires three parts: the HTML for the field, the CSS to hide it, and the functions to process it. If you use JavaScript to process your form (and are obviously already employing Graceful Degradation to ensure the form works without having JavaScript enabled in the browser), you should ensure the server is also ready to process the field in the same way — by ignoring or quarantining it.

Example 1 is a code sample that demonstrates a honeypot CAPTCHA.

Example 1:

<style type="text/css">

.interesting-div {

      position: absolute;

            top: -999999em;

      left: auto;

      width: 1px;

      height: 1px;






<div id="interesting-div">

<label for="body">If you see this, leave this form field blank

and invest in CSS support.</label>

<input type="text" name="body" value="" />