W3C home > Mailing lists > Public > wai-xtech@w3.org > July 2007

Re: reCAPTCHA implementation problems

From: Ben Maurer <bmaurer@andrew.cmu.edu>
Date: Sat, 14 Jul 2007 03:19:52 -0700 (PDT)
To: Gez Lemon <gez.lemon@gmail.com>
cc: "Gregory J. Rosmaita" <oedipus@hicom.net>, wai-xtech@w3.org, Colin McMillen <mcmillen@cs.cmu.edu>
Message-ID: <Pine.LNX.4.64-044.0707140303450.3624@unix35.andrew.cmu.edu>


On Sat, 14 Jul 2007, Gez Lemon wrote:

> Hi Ben,
> On 14/07/07, Ben Maurer <bmaurer@andrew.cmu.edu> wrote:
> Ben wrote:
> <quote>
> Sadly, we're unable to use tabindex to help us our much. The issue is that
> we don't control the entire web page. Most developers don't use tabindex
> for their entire form, relying on document order. What we do is allow the
> developer to say "please use this tabindex for reCAPTCHA". If they don't
> do that, we use document order to lay things out. So we only have one
> tabindex item to work with.
> </quote>
> It is generally better to follow the natural document order, because
> as well-intentioned as author-defined tabindex attributes are, they
> generally result in an unexpected tab order - particularly after a
> couple of updates, and the numbers specified for the tabindex
> attribute have been abandoned or have gone out of sequence.
> A solution that could work for you would be to put the CAPTCHA on its
> own page before or after the valuable resource. That way, you don't
> have to worry about anything else the developer has on the page, as
> your CAPTCHA would be a gatekeeper for the resource, with minimal
> integrations considerations.

Sadly using recaptcha as another page is a non-starter. First, we've 
committed to an API already which embeds the area on the page. Second, 
there are quite  afew studies that show every extra page in the signup 
process for an account has a dropout rate. Adding an extra submit to a 
signup page would be a bad UI decision for many users.

> One of the recognised problems with access keys are their
> discoverability. There are tools that can reveal access keys, but
> they're not used by the majority of users. There are also suggestions

By the majority of users, do you mean users in general, or those who can't 
use the mouse. A tool to revel access keys seems like an essential item 
for somebody who can't use the mouse, Otherwise thy can only navigate the 
document in one dimension (forward tab and back tab).

> Ben wrote:
> <quote>
> I think we can make the biggest impact if we can make reCAPTCHA accessible
> without degrading the experience for other users.
> </quote>
> If someone cannot request a new CAPTCHA or
> change the method, or get help, then it cannot in any way be
> considered accessible.

Agreed, these are critical functions.

> I don't agree with your assumption that
> keyboard users don't want to be able to navigate to items on a page,
> and allowing them to do so is somehow degrading their experience.

The users whose experience I think we are degrading are "casual" keyboard 
users, users who use tab to complete a multi form element.

Again, consider the wordpress form:

Name _____________________
Email ________________
Website _________________
Comment _______________________


  Your solution ___________  [refresh] [audio] [help]


I want the tab focus to be Name -> Email -> Website -> Coment -> Captcha 
Solution -> submit. If I need to press one of the three side buttons *I* 
use an out-of-band mechinism (the mouse)

It seems like there must be some other out-of-band mechinism to move the 
focus without resorting to the mouse. Tabindex should guide the input 
through the path that is most frequently used.

It's probably worth doing some user studies on people if we do decide we 
need to change the tab order. We need to make sure that we're not making a 
change that causes unexpected behavior for a large portion of our user 

Received on Saturday, 14 July 2007 10:20:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:33 UTC