Allow to play audio CAPTCHA via keyboard (or other means) only [#744264]

From [g.d.o](http://groups.drupal.org/node/55683).

1) when a user selects "play audio CAPTCHA", focus should be placed inside the input field into which the user has to type the CAPTCHA;

2) it is not clear if one is supposed to type in the alphabetic value for each enunciated mnemonic, or whether one is supposed to type in natural language phrases;

3) there is no explicit "submit" mechanism for the CAPTCHA challange; one should be added, otherwise, one gets into a loop between the CAPTCHA challange and the reply form's "Save" or "Preview" button; are the 2 submission mechanisms separate? if so, there needs to be an explicit CAPTCHA challange submission button

4) the audio captcha utiilizes a browser plug-in for control of playback of the audio captcha, yet such embedded controls are often inaccessible to users of assistive technology -- it would be better to have an actual form control that initiated a replay of the captcha (this is the approach taken by the reCAPTCHA project)

Comments

Comment #1

dave reid

he/him

English

Nebraska USA

commented 6 May 2010 at 13:24

- #1 seems perfectly valid and being added in #788968: Simplify the JS and captcha-fetching code
- #2 is also valid and handled with #768694: Alter help text on audio captcha
- How does #3 solve an accessibility problem? I don't think I've ever seen a CAPTCHA with its own submit button. If you hit the Preview button it should still check the CAPTCHA and if it was good hide it on the next form display prior to Submit.
- We'll have to look into #4.

Comment #2

daniel wentsch commented 19 May 2010 at 14:22

Subscribing.
Especially #4 might really be annoying for people navigating without a mouse (as I pointed out here #803248: Accessibility issue: Audio-CAPTCHA fails with keyboard navigation).

Comment #3

daniel wentsch commented 9 June 2010 at 12:36

Nothing new here?

Comment #4

nymo commented 9 June 2010 at 14:08

#4 is subjective as reCaptcha's audio is sometimes inaudible.

Comment #5

greggles

he/him

English

Denver, Colorado, USA

commented 9 June 2010 at 16:07

@jqtruong - is that because of the nature of their browser control or because of the quality of the sound file? I think it's the latter and suggest that Mollom ensure the quality of their sound files and the accessibility of the control to play the sound file.

Comment #6

dries commented 9 June 2010 at 16:16

Our sound files are rather easy to understand -- compare them, for example, with Google's audio CAPTCHA and you'll notice that Google's are much harder to understand. They add significant background noise, almost like cars and trains passing by. The reason is simple: spammers found automated ways to decode and answer audio CAPTCHAs.

Either way, specific suggestions on how to improve the quality of our sound files?

Comment #7

greggles

he/him

English

Denver, Colorado, USA

commented 9 June 2010 at 16:21

I think the Mollom sound files are great, but am not an accessibility expert.

I think the issue is the accessibility of the form control that starts the audio file playing.

Comment #8

daniel wentsch commented 10 June 2010 at 14:26

@Dries: just as greggles said, not quality is the problem.
It's simply not possible playing the sounds when navigating with keyboard only, thus making mollom inaccessible.

Comment #9

Everett Zufelt commented 21 June 2010 at 17:25

I would also ad that neither the visual or audio CAPTCHA are accessible to users with certain degrees of combined sight and hearing impairments. Although I cannot really suggest a good alternative that can still be technically considered a CAPTCHA. The most common approach is a textual question / response, but this has it's own problems.