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

Re: reCAPTCHA implementation problems

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Sat, 14 Jul 2007 11:11:35 -0400
Message-Id: <p0611041cc2be94135756@[]>
To: wai-xtech@w3.org
Cc: "Colin McMillen" <mcmillen@cs.cmu.edu>

Can we possibly separate two issues, here?

a) portable way to dispatch the sound that is the challenge or prompt 
in the audio CAPTCHA

b) universal interaction design for the collection of alternative 
CAPTCHA transactions


I think it was a) that Ben initially asked.

I agree that in order to have a practice we can recommend, we need to 
have b) as well.

for a) it would make sense to benchmark what Hotmail and AOL are using, because
those are production (high volume) sites.  Google is more new on the block etc.

for b) in addition to benchmarking the above and similar production
sites, we have the option (given that there are WAI-ARIA embedding
techniques that work in IE) of taking a fresh look. In particular on
yesterdays style guide call Lisa Pappas was talking about an example
where an accessible table presentation replaces (at a layout-region
level) the diagram presentation of some data relation. Perhaps the
interaction design should be that the audio and visual challenges are
visual options, not visually concurrent in the page. Since we need a
user event to launch the sound, why not repaint the visual scene at
this point and remove the elements one doesn't need from the form?
That is just one idea. The main idea is that this is an interaction
design. There needs to be advice up front that there are options, the
user has to have the chance to replay the audio prompt, everything
has to be doable from the keyboard, the most common case has to be
set up to be quick in the default presentation, etc.


At 1:36 PM +0100 14 07 2007, Gez Lemon wrote:
>Hi Ben,
>On 14/07/07, Ben Maurer <bmaurer@andrew.cmu.edu> wrote:
>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]
>Keyboard users are likely to press return and use a browser's
>autosubmit feature, rather than continue tabbing to the submit button.
>Ben wrote:
>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)
>I'm sorry to keep harping back to this point, but it's impossible to
>get away from the fact that that makes this approach inaccessible.
>Ben wrote:
>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
>That's an excellent idea, as I'm convinced your assumption is
>incorrect about keyboard users. Be sure to include people with a
>variety of disabilities in your user tests.
>I wish you well with this project, Ben, and hope you are able to come
>up with something that is truly accessible (or at least as far as that
>is possible by distinguishing humans by their ability to perform a
>Supplement your vitamins
Received on Saturday, 14 July 2007 15:11:47 UTC

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