Take the 2-minute tour ×

I want to include a CAPTCHA in my web application, but I also want to make sure that my web application is accessible to individuals with impairments or disabilities. How should I go about doing that?

For instance, does anyone know of any resources on how to make CAPTCHAs accessible, or how to accomplish similar security goals without sacrificing accessibility? Are there any best practices on accessibility and use of CAPTCHAs? Does anyone know of any readings on how to comply with accessibility requirements for government web sites, and ensure that a web site is usable by individuals with impairments or disabilities, when using a CAPTCHA?

I've seen that many sites offer an alternative audio CAPTCHA, which folks with visual impairments (or who otherwise cannot read the CAPTCHA) can use instead. For instance, I know that reCAPTCHA offers an audio CAPTCHA as an alternative to their visual CAPTCHA. However beyond merely noticing the existence of these alternatives, I'm totally ignorant about the right way to provide accessibility. Is an audio CAPTCHA a good way to provide accessibility? Are audio CAPTCHAs supported on all browsers (without additional plugins) and usable by all users with disabilities? Or, are there better approaches you would recommend? Are there existing solutions I can outsource to?

Update: I realize there are alternatives to CAPTCHAs that may be sufficient for many common situations, like fighting spam. I have investigated many standard alternatives, but I've found that they are not suitable in my particular situation. Therefore, I'm hoping you'll focus on what can be done for accessibility assuming I do need to use a CAPTCHA. (Listing alternatives to CAPTCHAs is not likely to be useful to me.)

share|improve this question

migrated from security.stackexchange.com Sep 28 '12 at 0:13

This question came from our site for Information security professionals.

Any reason you can't use an existing CAPTCHA tech that provides this (e.g. reCAPTCHA)? –  iivel Sep 27 '12 at 18:09
@iivel, you may notice that in the question I do mention specifically reCAPTCHA and ask if it is a good way to provide accessibility, if it (or some similar solution) is supported on all browsers and usable by all users with disabilities, and so on. Any insight into that would be very welcome! –  D.W. Sep 27 '12 at 18:12
reCAPTCHA is mostly 508 compliant and is cross-browser supported. Another option is to use a human solveable problem (match the image with the word) as a challenge question but those are much more difficult to make accessible. –  iivel Sep 27 '12 at 19:14
"I want to include a CAPTCHA" = why? –  DA01 Oct 1 '12 at 20:37
A human solvable problem would be the way to go for me, but in that case you have to make sure it's easy enough not to be another accessibility obstacle (for the elderly or cognitive impaired for example). But then again, a CAPTCHA can be by itself something quite difficult to interpret sometimes, so not very accessible in the first place... –  Yisela Oct 1 '12 at 22:04
add comment

5 Answers 5

We implemented a solution that measured the amount of time it took to submit.

  1. On arrival to the page with the form set a session variable with the time in
  2. On hitting the code that actually processes the form, check that the time it took to fill in and submit was not stupidly fast

Works really well and is completely accessible.

Here's a demo: http://www.frankdesignltd.co.uk/blog/using-sessions-to-stop-spam/

share|improve this answer
+1, as it may be useful to other visitors -- but as I explained in my response to Polynomial, this does not actually answer my question. I did investigate these sorts of alternatives, and I really do need to use a CAPTCHA, not one of these alternatives. I'm not asking for alternatives to CAPTCHAs; I'm asking about accessibility if I do need to use a CAPTCHA. –  D.W. Sep 27 '12 at 15:42
I suppose creating a bespoke method (which is kind of what we did with the timer) would be another possibility. If you displayed a CAPTCHA code in an alternative way than any other solution. For example: "Tick the nth box if you're human" –  beingalex Sep 27 '12 at 15:57
That's not suitable against the threat model I'm working with. In my situation, the CAPTCHA is being used as a low-cost way to deter attacks that are crafted to target a specific site. I want to deter automated guessing and other large-scale attacks against that site. "Tick the n-th box" is too easy to script up an attack on (for one thing, the number of boxes will be so small that random guessing will succeed with high probability). All I can say is, I did diligently investigate the alternatives, and I do have reasons for saying I want to use a CAPTCHA (and make it accessible). –  D.W. Sep 27 '12 at 18:01
add comment

Unfortunately, audio CAPTCHAs are not a good way to provide accessibility. For example, the current version of the audio alternative in reCAPTCHA is causing lots of problems for blind users. You can see some discussion in the reCAPTCHA Google group.

Some researchers at Towson University were working on an accessible CAPTCHA alternative that paired nontextual images with audio (PDF abstract). The paper was published by the American Society for Engineering Education in 2009. I haven't seen any updates since the initial paper.

CAPTCHAs are an arms race, and right now it seems the bots have the upper hand. If you are trying to prevent fake user registrations, rather than block spam content, there's less room for content analysis. Have you considered collecting some content just to give those tools something to work on? So you would add a freeform text field to your signup form with an open-ended question, then turn something like Akismet or Mollom loose on it.

share|improve this answer
add comment

As far as I'm concerned, CAPTCHAs are dead. There has been so much investment and research into defeating image-based and audio-based CAPTCHAs that you have to make them almost unreadable (or inaudible), and the bad guys can still hire a dozen people in the 3rd world to solve them anyway.

I've found the best method is to include a dummy form field:

<form method="POST" action="/target">
    <input type="hidden" name="userid" value="1337" />
    <div class="formField" id="contactFieldName">
    <div class="formField" id="contactFieldEmail">
    <div class="formField" id="contactFieldSubject">
        Subject: <input type="text" name="subject" value="" />
    <div class="formField" id="contactFieldFoo">
    <textarea rows="15" cols="80" name="message"></textarea>

Then, in the CSS:

#contactFieldFoo {
    display: none;

Finally, in your target script, ensure that the "foo" field is blank. This ensures that all drive-by spam bots get ignored, which is (surprisingly) most of them.

share|improve this answer
An input of type 'hidden' does the same trick. In Combination with a Captcha it is might even be safer, as it prevents human spammers (somehow) –  Pit Sep 26 '12 at 18:54
I think saying "CAPTCHAs are dead" is too simplistic. There are situations where they do add value. Your proposal helps against mass attacks (the attackers are spammers who are trying to post spam on a million blogs); for that, you don't have to outrun the bear, you just have to outrun the other victims. However, in my case I'm concerned with targeted attacks that focus on a single valuable site (e.g., the attackers want to create a million accounts on that one site). Your proposal doesn't help with that. So, while I like your answer for many use cases, it doesn't solve my particular problem. –  D.W. Sep 26 '12 at 20:20
P.S. To put it another way, you didn't actually answer the question. :-) In my situation, a dummy form field does not meet the same security needs as a CAPTCHA. So, I'm still interested in what I should do for accessibility, in situations where a CAPTCHA is needed (for whatever reason). (Nonetheless, +1, as your suggestion might be useful to others who stumble across this page!) –  D.W. Sep 26 '12 at 20:23
@D.W. Yeah, I guess that's true. I just have an aversion to them! –  Polynomial Sep 27 '12 at 7:38
add comment

I found a useful analysis of the accessibility of several CAPTCHAs, including reCAPTCHA, the AOL CAPTCHA, and the Google CAPTCHA. It highlights some issues to watch out for, including the order in which icons and text entry fields are presented and the implications for the workflow of someone who is using a screen reader.

Caveats: The analysis was written over 3 years ago, so I don't know if its comments remain applicable. Also, it is not clear whether there is any existing off-the-shelf library/software/toolkit that a web application designer can use, if he/she is developing a new web application and needs an accessible CAPTCHA. (reCAPTCHA is readily available, but the analysis rates its accessibility as poor. The analysis rates AOL and Google's CAPTCHA much better, but those are not generally available to others.)

share|improve this answer
add comment

I recently read quite a lot over Captcha's usability & accessibility, and I found out that the "honeypot" method seemed to be the most useful & secure alternative up to now as opposed to all other alternatives.

Now I know that you want to use the Captcha and nothing else in your case. Out of all my readings, it seems indeed that ReCaptcha seems the best alternative then: not only it uses words that are already known to be unrecognized by OCR and then only used in captcha, which is quite secure and also usable as these words are existing words and not just random character strings.

Now you have to be aware that it takes some 10 sec. on average to solve an image (text) Captcha while it takes some 28 sec on average to solve an audio captcha when it is audible. This makes audio Captcha not very usable though it is the only alternative up to now for people with impairments.

Some readings that might be helpful for you :







share|improve this answer
add comment

Your Answer


