Posted by Everett Zufelt on July 27, 2009 at 2:10pm
The other day I posted to the accessibility group on g.d.o and was asked to solve a CAPTCHA. As a screen-reader user, posting in an accessibility forum, I was quite surprised.
Now, I was made a little less frustrated when I noticed that the CAPTCHA included an audio alternative. However, the audio is sufficiently unclear that it was a challenge for me to solve on the first attempt, and I cannot imagine the challenge it would be for someone who is hearing impaired.
In short, audio / visual CAPTCHAs, even when used together, are a poor accessibility practice.
Would love to hear what others think about this issue.
Comments
CAPTCHAs Can Be Tough But Shouldn't Be Impossible
My experience is that CAPTCHAs are often tough and even though I'm not visually disabled, I've failed to visually interpret them correctly on the first attempt. My rule of thumb is that if they're not challenging for humans, they're not challenging for SPAM bots. Since the same level of difficulty needs to apply to the audio version, those can also be tough to interpret by hearing. I think ReCAPTCHA.net does a good job of this by playing audio that has some form of distraction in it (static, noises, etc.) (See http://recaptcha.net/learnmore.html)
I don't agree that audio/visual CAPTCHAs are, by default, a poor accessibility practice. Since so many sites have only done visual CAPTCHAs for the longest time, I think it's great to see an increase in the number of CAPTCHA alternatives that are starting to include audio alternatives. There's definitely a variety of quality of CAPTCHAs out there to choose from though.
Mark W. Jarrell
Manager of Web Services
Jones Knowledge Integration Group, Inc.
http://fleetthought.com
http://www.jones.com
http://www.jonesdifference.com
http://www.jiu.edu
Twitter: attheshow
Mark W. Jarrell
Online Applications Developer
Richland Library
http://www.richlandlibrary.com
http://fleetthought.com
Twitter: attheshow
CAPTCHA this...
I hate CAPTCHAs. They're hard enough on the large screen. They're near impossible on the small screen. I see well (with correction) and hear well, but CAPTCHAs of both types are hard for me to interpret.
Generally, any effort to screen out troublemakers should be considerate of legitimate visitors. CAPTCHA is annoying to us, but merely a new game to the troublemakers.
Consider this, heard from a presentation last month before the Usability Professionals Association: Spambotters now have sites where anyone who correctly interprets the CAPTCHA of the moment for the spambot gets to view a few minutes of porn for having succeeded at that task. So spambots are getting around CAPTCHAs with the unwitting assistance of humans in search of an online thrill. If that persists, no CAPTCHA you design will successfully screen out the spambots.
There has to be a better solution. At least there must be one that isn't so rude.
Captcha issue filed
I want to let you know that there is an issue about this at http://drupal.org/node/532186
@attheshow
You say: "My rule of thumb is that if they're not challenging for humans, they're not challenging for SPAM bots. Since the same level of difficulty needs to apply to the audio version, those can also be tough to interpret by hearing".
The level of difficulty involved in interpreting a visual or audio captcha is dependent on the perceptual ability of the individual doing the interpreting. Therefore, as the visual or auditory acuity of the interpreter diminishes the difficulty of interpretation increases.
So, I would have to stand by my original statement, that audio / visual CAPTCHAs, even when used together, are a poor accessibility practice.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Captcha Issue
And there is more to accessibility of CAPTCHA's than how difficult it is to decipher - I wrote about that here: http://jimthatcher.com/captchas.htm. But specifically on the audio CAPTCHA, I am convinced that they are much harder to solve than visual CAPTCHA, unnecessarily so.
Even more to CAPTCHAs than that, Jim
Accessibility of the interface is, of course, important, Jim. In your article, you do a great job of identifying barriers to accessibility and showing how some developers have removed those barriers from their sites. (I still have questions as to whether the methods used would be accessible to people who have various cognitive disabilities — for example, mild forms of dyslexia.)
But I see two other aspects to consider. The first is whether the technique used provides a significant barrier to spambots. But if spambotters have figured out ways to get people who have no life to solve the CAPTCHAs that their spambots encounter, then CAPTCHAs will no longer exclude spambots. Only the last example in your article seems to be immune to this development. In that example, the user must read a six-digit number from the screen, call a toll-free number, enter that six-digit number on the phone keypad, receive a new six-digit number over the phone, and finally enter that new number into a text field on the Web form.
This raises the second aspect we should consider: Does the bot-screening technique degrade the user experience for anyone who is not a spambot? I can't think of a single CAPTCHA that doesn't at least annoy the legitimate customer.
But Jared Smith's list of highly effective bot-screening methods includes a number of options that are completely unobtrusive to anyone but spambots. None of them impair accessibility.
Jared points out conditions under which these methods would not be sufficient, but, frankly, I've never been asked to complete a CAPTCHA under those conditions. In my experience, when that higher level of security has been needed, the site hasn't relied on a CAPTCHA.
So why are we even discussing CAPTCHAs? No matter how we approach the issue, better alternatives exist.
And the irony of it all: When I finished this comment and hit "Submit," our forum responded, "We are sorry, but the spam filter on this site decided that your submission could be spam. Please fill in the CAPTCHA below to get your submission accepted."
AAAARRRRGH!
Cliff said ...Only the last
Cliff said ...
Hi Cliff - I was told that it would be easy to code a solution to this - granted the spammers won't get people to solve it for them - but those spammers are resourceful and if they wanted to get in it would be easy. So you don't want to use this idea to guard the issuance of free email addresses on GMail.
Another comment here was that the RiteAID CAPTCHA (referenced at the end of http://jimthatcher.com/captcha.htm) was really "nice." Yes it is if you are a human trying to do something; But again I've been told it is no barrier at all to the spammers IF they wanted to "get in".
I definitely agree with what
I definitely agree with what you're saying about the difficulty being relative. I think that the Mollom practice is a great one. (Assume that the person is a human by default, and only challenge the user with a CAPTCHA if the Mollom system interprets the text as possible SPAM.)
Mark W. Jarrell
Online Applications Developer
Richland Library
http://www.richlandlibrary.com
http://fleetthought.com
Twitter: attheshow
Continued CAPTCHA Crazyness
I just added some text CAPTCHA's to a client's site today that was getting spammed, so thought I should add to this.
Jim, I do really like your audio CAPTCHA example. Mollom is good, but this is pretty ideal. https://www.riteaid.com/myriteaid/login.jsf
Cliff, with Jared Smith's list. Can you think of any reason why any of those shouldn't be integrated by default with Drupal? Is Drupal currently using any of these by default:
* Detect spam-like content within submitted form elements
* Detect content within a hidden form element
* Validate the submitted form values
* Search for the same content in multiple form elements
* Generate dynamic content to ensure the form is submitted within a specific time window or by the same user
* Create a multi-stage form or form verification page
* Ensure the form is posted from your server
@aththeshow I'd like to see Mollom start to assess other content contributed by the user. Certainly a new user could possibly be producing spam after they have gone through the registration phase. However a long term user who has produced other approved content really should never be presented with a CAPTCHA after they have logged in.
Mike
ps. So brilliant that in responding to this post I have to fill in CAPTCHA. Why on earth is this content suspicious.
--
OpenConcept | CLF 2.0 | Podcasting
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
G.D.O seems to detect spam-like content
I doubt that's a default function of Drupal, though. And it seems to me that g.d.o considers any post that has an embedded url to be "spam-like content." Unless critiquing CAPTCHA is spam-like, Mike, I see nothing else in your or my post that fits that description.
Mike, I think incorporating those features into Drupal by default would be a good idea. On any sites I develop, I plan to include the form field that is hidden from humans but found (and thus completed) by bots. If there's content in that field, the form goes to the trash.
Now we'll see if I have to endure a CAPTCHA on this.
Cliff
jared's list
Theoretically Mollom does that for us.
This may work on tiny sites, but g.d.o and other big sites have to deal with spam bots that are smart enough to read text. This won't stop the bots.
We do this already.
We only have a subject and a body, so this isn't really applicable. If it were, I would hope that Mollom would be doing this automatically for us.
drupal_valid_token (which is part of the FAPI) already does this.
This seems like a huge annoyance without much real benefit. It's easy these days for bots to handle multi-page forms (our own simpletest browser in drupal core does it all the time).
--
http://growingventuresolutions.com | http://drupaldashboard.com | http://drupal.org/books
knaddison blog | Morris Animal Foundation
No URL, no CAPTCHA required
Let's see if g.d.o. itself triggers a CAPTCHA.
No, it didn't. Maybe it's only suspicious URLs — such as the notorious WebAIM.
Nope. I'll quite while I'm ahead — and remain dumbfounded.
Here's a related item
In another forum, gabrielu recently posted this "invisible challenge" for Drupal's CAPTCHA module, based on Scott Allen's similar plug-in for WordPress. I haven't tested it (I'm still trying to get my first significant site to the point where the customers can run it mostly on their own), but it sounds like it follows the general approach espoused by Jared Smith. If others have time, it's worth a look and some feedback. (One drawback for accessibility: it uses Java script
Jim, both Jared Smith, in his general comments, and Scott Allen, in his explanation of how the WordPress plug-in works, make a valid point: Nothing we do will be completely effective against spambots. After all, whatever we try will boil down to an algorithm, and if you can write an algorithm for your bot-screening method, then some programmer somewhere can write the code a bot can use to get around it. But most spammers won't — at least not right away. So the game is to do whatever we can to screen out well over 99 percent of current spammers without inconveniencing legitimate customers, and it seems to me that Jared's and Scott's approaches achieve that standard.
(Now, will this post trigger a CAPTCHA for me to complete?)
Wow! Once again, no CAPTCHA required!
I'm on a roll! ;-)
My suggestions
Here: http://groups.drupal.org/node/24400 (hair trigger Mollom Captcha is a usability issue) - to at least treat established users with some respect!
benjamin, agaric