Alter help text on audio captcha

Adding accessibility tag.

Also wondering what the process is right now for reCaptcha which I've heard has a pretty good transition to the audio playback.

Agreed. I pointed out in #788968: Simplify the JS and captcha-fetching code that we should really be changing the help text when the user switches CAPTCHAs since they could have different ways of being solved.

Looked into reCaptcha's audio method and I actually thought it was pretty hard; they give you an audio clip of someone and you have to write down almost a whole sentence. The clip I was given was spoken really fast. The one positive thing with their approach is they give you the instructions at the beginning of the audio file, which is probably what we should be doing.

Instructions are good. Let me see if I can come up with some better solutions for how this could be implemented.

I go this link about discussions between reCaptcha & accessibility here:
http://www.w3.org/WAI/PF/wiki/CAPTCHA_v2

Although it may be better for either deaf or blind users there is still no way for it to be available to someone who is both deaf and blind.

I'm assuming that people who are both deaf & blind would use a braille reader to navigate the web. I'm pretty sure it is a pretty small community, but it is important to think about people with multiple disabilities.

We could easily add instructions to the audio CAPTCHA, but we should still correct the help text.

If we add instructions to the audio CAPTCHA, what should we say? I might need some help with wordsmith-ing to keep it concise. Long help texts can be really annoying.

Also see #464400: Disable audio captcha if current language is not English, which would be a -1 for any screen-reading users since they would not have any way to complete the captcha.

Considering the words are from the ICAO/NATO spelling alphabet, which 'The paramount reason is to ensure intelligibility of voice signals over radio links.' which I'd say is a pretty good reason it should be used. :)

We might be able to make that work over time. Until then, it might be a good idea to pass a 'language' field to mollom.getImageCaptcha / mollom.getAudioCaptcha.

We could then gather some server-side statistics about what languages to support first.

Since this issue started I've been talking a lot with accessibility experts about CAPTCHA generally. There is a way that the present approach to them is broken for accessibility.

With the advances in computer "vision" and voice recognition there is an effort to make it as hard as possible for anyone to understand. Computers are just getting better at making sense of our world, so images & voices are becoming increasingly distorted. Given Google's experience with voice recognition it's understandable that they would be worried and be able to easily test how easily computers can understand their voice CAPTCHA's. However, this is a note I got earlier from twitter:

Jennison @mgifford You've got it. You need really discriminate hearing to solve the Google captchas. Takes me up to ten of those b/f I get one right.

The whole discussion I pointed to in #4 is based on the idea that CAPTCHA's are assuming you are not both deaf and blind. reCaptcha may be the best example if you've got good eyesight or good hearing, but it's not useful for everyone. Increasingly it seems you can't have any vision impairments & need to have avoided loud music as a teenager too. So how are you supposed to build a tool that is universally accessible, but also excludes robots? Also from twitter:

SteveBuell @mgifford There will never be just one way that works for all.

Seems like we need to be looking at providing choices and looking to integrate with O-Auth types tools as an option. Why not offer a visual CAPTCHA, an audio CAPTCHA or an O-Auth login such as MSN Passport, Yahoo! ID, Google Acct, OpenID? These are all tools that can be gamed, as often you are dealing with actual people in who are getting paid (very little) to submit links like this in comments.

There are bigger issues and bigger players involved in the anti-spam discussion. One of the comments from IRC suggested a much broader approach:

oedipusnj @mgifford we need a #standards-based alternative 2 #CAPTCHA tests; where can such a mechanism be designed/implemented? W3C Incubator Group?

However, I think that providing options instead of visual/audio CAPTCHAs will help. I'd certainly use openID rather than complete most captcha's today. Had a quick note on recording better audio captcha's that also came up in the discussion. Eramp has a nice set of documentation on understandable recordings.

Then its up to the site builder/administrator to add OpenID and enable the 'bypass mollom protection' for certain user roles. I don't see anything actionable we can do here from the Mollom end yet besides making sure we're providing audio instructions on how to solve the captcha prior the audio captcha itself.

I'd like to see it all on the same form and managed by Mollom.

If OpenID is enabled on Drupal then it should just be one option that's made available for people to use when being prompted for anti-spam confirmations.

Having users register with OpenID for a user account in order to bypass mollom protection is too much for most admins to set up. It would work, but wouldn't be as nice. Also, most folks aren't going to do it.

Offering a combined CAPTCHA/O-Auth solution is going to make Mollom stand out for accessibility.

bumping version; see also #273964: Accessibility problems with audio CAPTCHA

on second thought, i suggest folding this discussion in with #273964: Accessibility problems with audio CAPTCHA.

For anyone still following this discussion, the essential issue has now been addressed in the development branches.
https://drupal.org/node/273964