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

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

From: David Poehlman <david.poehlman@handsontechnologeyes.com>
Date: Tue, 17 Jul 2007 13:34:23 -0400
Message-ID: <000801c7c898$b9058780$0401a8c0@HANDS>
To: "Ben Maurer" <bmaurer@andrew.cmu.edu>, "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>

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>; 
Sent: Tuesday, July 17, 2007 1:19 PM
Subject: Re: reCAPTCHA: focus moves after audio fired, some thoughts


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:


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)

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:25:16 UTC