Re: reCAPTCHA: focus moves after audio fired, some thoughts

the google link works just fine.  one thing they do is repeat the string 
with the word again before the second itteration.  I also like their help 
for screen readers which provides a way to deal with a human being in case 
of last resort.

----- Original Message ----- 
From: "Ben Maurer" <bmaurer@andrew.cmu.edu>
To: "Joshue O Connor" <joshue.oconnor@cfit.ie>
Cc: "Gregory J. Rosmaita" <oedipus@hicom.net>; "Chris Blouch" 
<cblouch@aol.com>; "Colin McMillen" <mcmillen@cs.cmu.edu>; 
<wai-xtech@w3.org>
Sent: Tuesday, July 17, 2007 1:19 PM
Subject: Re: reCAPTCHA: focus moves after audio fired, some thoughts



Hey,

On Tue, 17 Jul 2007, Joshue O Connor wrote:

> Gregory J. Rosmaita wrote:
>> ben wrote:
>>> The focus-moving is mostly for the demo. It makes it much easier
>>> to try out the demo (sort of like the google.com homepage). Also,
>>> we move the focus to the input box after you switch to/from an
>>> audio captcha. Any thoughts on this?
>> unquote
>>
>> when you need to open the audio captcha challange in a media player,
>> like as not, focus is going to be grabbed by the media player, unless
>> one is quick enough to cycle back to the page [...]
>
> Thats exactly what happens. I just did some testing of the CAPTCHA. It
> was rather clumsy as the opened file must be stopped and started by the
> user while they toggle backwards and forwards between the browser and
> the media player. Also the user has to listen attentively for the audio
> - as well as the output from the screen reader - and one can drown out
> the other. In our test the media player appeared embedded within the
> widget but it seemed to be inaccessible because when viewing or
> listening to content embedded within a media player that is embedded
> within a browser, the keyboard shortcuts that the screen reader user
> activates to play or to stop the embedded content are in the control of
> the browser and not of the media player. In our test the user could tab
> through the controls of the media player (in this case windows media
> player) but there was no screen reader output when these controls had
> focus.

Did the embedded player work at all (did it play a sound, but the controls
didn't work) If so, we can just hide the actual controls. We may be able
to implement a "play again" button.

An example of this is:

http://google.com/accounts/NewAccount

Does that page's captcha work any better.

> This was not an issue when we downloaded the audio file by clicking on
> the "can't hear the audio button?" but as Gregory mentioned the user
> then has to somehow control the audio, cycle back to the page etc. So it
> is not ideal, even though it works.

That button is a fallback. Nothing more, nothing less. Was the button
easily discoverable even though it was inserted behind the "switch to
audio " button in the dom?

Also, how was the experience finding that button (eg the tab order issues
we've commented about)

-b

Received on Tuesday, 17 July 2007 17:41:57 UTC