- From: Joshue O Connor <joshue.oconnor@cfit.ie>
- Date: Tue, 17 Jul 2007 17:09:35 +0100
- 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 UTC