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:19:46 UTC