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

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

From: Joshue O Connor <joshue.oconnor@cfit.ie>
Date: Tue, 17 Jul 2007 17:09:35 +0100
Message-ID: <469CE9BF.4040609@cfit.ie>
To: "Gregory J. Rosmaita" <oedipus@hicom.net>
Cc: Ben Maurer <bmaurer@andrew.cmu.edu>, Chris Blouch <cblouch@aol.com>, Colin McMillen <mcmillen@cs.cmu.edu>, wai-xtech@w3.org

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.

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.

I guess this is not an issue which can be controlled by the reCAPTCHA
developers unless they wish to go down the road allowing the user to
control embedded content with mapped keystrokes via some video/audio
API, that may not be a bad idea, basically if the audio content could
somehow be controlled within the browser via the keyboard with simple
play/stop/rewind functionality.

In the user test my colleague later commented that he would like to be
able to control the content in the browser without having to open
another media player.

Josh
Received on Tuesday, 17 July 2007 16:09:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:43 GMT