Re: reCAPTCHA implementation problems

Would it make some sense to place a help link just after the captcha 
solution and have that move focus to various extra info? Something like 
this:

name_______
location_______
etc______

<captcaha>

[help]

solution_______________

#help
    More description
    Load another captcha
    Play an audio equivalent and move focus to solution field

So help is a link inbetween the captcha and the solution. If followed it 
take the user to the help anchor which has some more descriptive text, 
the ability to load up a new captcha or play the audio version.

In general it appears that there are three segments of users: mouse 
only, sighted keyboard users and screen reader keyboard users. In the 
first case they won't care much about the extra help link inbetween. In 
the second case if the user is tabbing around, landing on help before 
the solution shouldn't be that disruptive. It actually seems pretty 
common to have a "what is this?" link after uncommon web constructs. For 
the screen reader user they will get the image with a reasonable alt 
text - maybe "this is a security image, click help for more info" - and 
then tab along to the help link and then to solution. If they are not 
sure what's happening then they follow the help link. If they get past 
the solution field they land on the help link. So in any case help is 
close at hand and it shouldn't interfere much with the visual UI navigation.

CB

bmaurer@andrew.cmu.edu wrote:
>
> Hey,
>
> 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 _______________________
>         _________________________
>
> CAPTCHA
>
>  Your solution ___________  [refresh] [audio] [help]
>
> [submit]
>
>
> 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 base.
>
> -b
>

Received on Tuesday, 17 July 2007 17:38:23 UTC