Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[weekend reading] CAPTCHA and accessibility

Weekend Reading weekend_reading at lists.stanford.edu
Wed Jul 22 16:14:08 PDT 2009


Zachary E Chandler wrote:
>
> John,
>
> I know that CAPTCHA gives you hives, but is there an alternative? The
> ability to filter robot comment spam can be extremely important. Have
> you seen instances of audio CAPTCHA? Do you have an opinion about Mollom
> methods (http://mollom.com/)? I am interested to hear your opinions.
> Feel free to cc any list that you want in your response.
>

Not Hives, ulcers...

In many ways, this ground has been tread before, however, since Zach is 
asking (and also asks about a new service) let's take a look:

The biggest accessibility issue with CAPTCHAs is that they are not 
accessible to Visually Impaired users, as the entire premise of the test is 
to visually interpret deliberately distorted text.  As a result, they shut 
out not only blind user, but users with low vision (such as seniors) or 
others with any number of visual disorders beyond actual blindness.[1] 
Recently, Audio CAPTCHAs have surfaced whereby an audio track is played and 
users are to then type in what it is they heard.  This of course is still a 
total failure for deaf/blind users, but is also a significant problem when 
also associated with tech/external issues such as excessive ambient noise, 
poor bandwidth, no soundcard or speakers, etc.  As well, because the audio 
files are small and short to begin with, even fully hearing users often 
struggle to comprehend what is being 'said'.  Finally, from a plain 'ol 
usability issue, CAPTCHAs (audio or visual) elicit a fair bit of frustration 
even from mainstream users, with a common refrain that they are difficult to 
use period.

In 2005, Matt May (W3C, now with Adobe) authored a W3C note[2] that covers 
the entire issue, along with points addressing a false security, means and 
methods of cracking CAPTCHAs, etc.  While the web has progressed in the past 
4 years, many of the issues and comments are relevant today.

"CAPTCHA is now in frequent use in the comment areas of message boards and 
personal weblogs. Many bloggers claim that CAPTCHA challenges are successful 
in eradicating comment spam, but below a certain threshold of popularity, 
any other method of comment spam control should be reasonably successful --  
and more accessible to users with disabilities."

UK based web accessibility specialist Gez Lemon summed it up best when he 
wrote: "What online services that attempt to protect their resources (using 
CAPTCHAs) actually want to know isn't the *ability* of the person at the 
other end of the connection, but whether or not they are *trustworthy*." 
(emphasis mine)  His blog article on alternate means of making that type of 
determination is/was a thought-provoking read. [3]

Jim Thatcher (of Section 508 fame) wrote a recent article (March '09) that 
took yet another look at CAPTCHAs, and revealed a problem with the most 
popular visual/audio CAPTCHA program (reCAPTCHA) and noted that activating 
the reCAPTCHA solution had a serious flaw: "... the icons are a huge 
problem. These icons are not in the tab order. You cannot activate any of 
those icons from the keyboard. This is almost as fundamentally inaccessible 
as the CAPTCHA itself." [4] His article also offers some interesting, 
larger-scale alternatives for high-traffic sites (in particular the 
AnnualCreditReport.com site: once you have entered 'state' in the 
registration process, a random 6 digit string is generated and a toll-free 
(1-866) number is provided: call the number, enter the 6 digits and it 
echo's back 6 more, which you then enter into the form.  Highly effective, 
very accessible, but with some overhead beyond most small blog sites.)

So what to do?  Normally, if all you are trying to do is eliminate blog 
spam, a number of simple additions to your form is all that is required. 
Jared Smith of WebAIM wrote an article[5] that outlines a number of 
solutions he's implemented in the past with great success, suggestions such 
as:

    * 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

Don't do code?  CMS platforms (such as WordPress) are starting to produce 
non-CAPTCHA alternatives [5] that use a combination of time-based hash 
(a.k.a. Time Based Tokens, TBT) and JavaScript (AJAX). (I am currently using 
this plugin on my personal blog, and experience virtually zero spam).

Another potential solution (discussed in Matt May's 2005 article, and 
currently my preference) is 'Federated identity systems' or Single Sign-on 
solutions.  Many large social networking sites (such as Google, Facebook, 
MySpace, Twitter, Windows Live, and Yahoo!) now take advantage of this 
method, and APIs are available to implement solutions such as OpenID on even 
small blog sites [7]. The advantage here is once you are 'authenticated' on 
one of these 'networks', the 'trust' (that Gez Lemon spoke of) is 
established: if you trust Twitter (for example) and Twitter 'vouches' for 
Joe Smith, then by extension you trust Joe Smith.  The beauty here is that 
any virtual host can be an authenticator: I've set up an OpenID solution 
using my personal domain (foliot.ca), as I have access to the server. It's 
fast, simple, and effective. (Zach, we've discussed this before, and perhaps 
now is the time to re-address the idea with ITS at Stanford of establishing 
OpenIDs associated to SUNet IDs...)

Zach also asked specifically about the MOLLOM.com 'solution', which uses a 
number of heuristics to pre-filter in-bound traffic; however, once again, 
when the Mollom system is in doubt, it forwards users to a CAPTCHA page for 
verification.[8]  While solutions such as this are generally transparent to 
most users, when there is an issue, it will result in the same problem that 
the system is trying to avoid - CAPTCHAs! So Zach, thumbs down I'm afraid...

Eliminating blog spam is a real issue, however CAPTCHA is just not the best 
way of doing this.  Fortunately, better methods are emerging, and 
implementing these better means is becoming increasingly easy to do. 
Avoiding CAPTCHAs reduces access barriers for all users, and improves 
usability across the board.

Cheers!

JF

Resources:
[1 http://www.youtube.com/watch?v=4jrgMlufa7w ]
[2 http://www.w3.org/TR/turingtest/ ]
[3 http://juicystudio.com/article/accessibility-of-captcha.php ]
[4 http://www.jimthatcher.com/captchas.htm ]
[5 http://webaim.org/blog/spam_free_accessible_forms/ ]
[6 http://amazingwordpressthemes.com/wordpress-spam-blocker ]
[7 http://www.plaxo.com/api/openid_recipe ]
[8 http://mollom.com/how-mollom-works ]



More information about the weekend_reading mailing list