Hi!

I've tried the Mollom module and it is pretty good. The sound captcha functionality though, is kind of nasty. If you click on it you get a angry warning dialogue stating that you don't have Quicktime plugin installed. This is really a very bad user experience. Please add the possibility to disable sound captcha. What is the reason to have sound captcha that throws a text-only error message if the right plugin isn't installed? :)

Have you ever tested the sound captcha with a blind user? Do they find the Captcha character field?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

BioALIEN’s picture

I fully agree with the assessment here. I just tested it with IE7+Win and it asks to install/run ActiveX for Windows Media Player plugin! Even after I enabled it, it didn't work, I did not hear anything and the sound did not play.

I fully believe we should:
1. Have an option to disable the voice captcha
2. Make the voice captcha in flash.

For comparison, I just tried the one used by Google: https://www.google.com/accounts/NewAccount

Is it me or is the voice captcha completely drunk? I couldn't distinguish what on earth was going on and I am English! It's sounded like a whole army of people talking at the same time. I was under the impression voice captcha reads out what the image captcha is? In this case, mollom should not be replacing the image captcha placeholder with the voice captcha player but should just fire the sound file alongside the image captcha?

Gurpartap Singh’s picture

Component: User interface » Code
Category: feature » bug
Priority: Normal » Critical

I was under the impression voice captcha reads out what the image captcha is? In this case, mollom should not be replacing the image captcha placeholder with the voice captcha player but should just fire the sound file alongside the image captcha?

+1!

Boletus’s picture

I disabled the Mollom module. All in all, the usability of it was not good enough.

Dave Reid’s picture

Title: Disable sound Captcha » Improve the audio Captcha
Version: 6.x-1.2 » 6.x-1.x-dev
Priority: Critical » Normal
Status: Active » Postponed

Ugh... the Google audio captcha is horrific in my computer. It sounds like a bunch of drunk aliens. :)

So far the following ideas have been proposed:
1. Convert the from Quicktime to Flash.
That seems valid and is usually the most supported and commonly found browser plugin. This will require a significant change in the API itself.

2. The audio captcha should not replace the image captcha, and should read the value of the image captcha instead of a new value.
This also seems reasonable, but this also will require a significant change in the API.

If you have any more ideas, please post them here. Marking as postponed for now since we'll have to look into how to implement this.

Dave Reid’s picture

Status: Postponed » Fixed

Audio captcha is now a flash plugin, which works a lot better for everyone.

Dries’s picture

Wish we could use the <audio> tag in HTML5. :)

Dave Reid’s picture

I would love to see use try to lead on the HTML5 tags. I'll look into seeing if we can figure out way to use the HTML5 tag if its supported.

Dries’s picture

See http://demos.w3avenue.com/html5-unleashed-tips-tricks-and-techniques/sam... for a demo that can be used to test browser compatibility. IE doesn't seem to support the <audio> tag yet -- according to the demo page.

Dave Reid’s picture

Title: Improve the audio Captcha » Investigate trying HTML5's <audio> tag instead of Flash
Version: 6.x-1.x-dev » 7.x-1.x-dev
Category: bug » feature
Status: Fixed » Postponed

Moving to the HTML5 request as postponed.

Dave Reid’s picture

Apparently all we'd need to do is if (!!document.createElement('audio').canPlayType)

Everett Zufelt’s picture

Issue tags: +Accessibility

tagging

sun’s picture

Issue tags: -Accessibility

If we will start to inject technically invalid HTML5 markup into non-HTML5 documents, then I already start to hear geeks crying. #omg 8-)

Joking aside, HTML validators will complain, and a nitpicky enterprise might stress. Though, of course, we'd have valid reasons for being invalid. Just mentioning.

sun’s picture

Issue tags: +Accessibility

.

MacRonin’s picture

@Dries HTML5/JS player http://drupal.org/project/jplayer
http://www.happyworm.com/jquery/jplayer/

jPlayer is a jQuery plugin that allows you to:

* play and control audio files in your webpage
* create and style an audio player using just HTML and CSS
* add sound effects to your jQuery projects
* support more devices using HTML5

All of this with HTML5 support for compliant browsers that allow mp3 or ogg format, while supporting other browsers using mp3 format with no visible Flash.

aspilicious’s picture

I mailed with Dries about this.
I suggest a double approach.

- Using html 5 for browser that support those tags. (all Except <= IE8)
- Use flash for the others ( <= IE 8)

<audio src="horse.ogg" controls="controls">
Your browser does not support the audio element.
</audio>

If we can replace the "your browser does not support the audio element" text with the flash script then we have a safe, valid 2 way solution.
As this is just an accessibility issue and most people needing this kind of solution aren't using IE. I think this is a valid alternative for the next few years until every browsers support the audio tag.

sun’s picture

Status: Postponed » Active

I agree with the consensus that accessibility is more important than übergeeky W3C standards validation.

Squeezing the Flash-code within an audio tag, in the hope that browsers will render it, is not a good idea. We can negotiate in JavaScript whether the browser supports HTML5, and if it does, pass a different argument to our server-side callback to retrieve the HTML for the audio CAPTCHA.

I also agree with changing the audio CAPTCHA to automatically start playing - although that won't cut it for most cases, I think. (starting too fast, perhaps also playing too fast)

Lastly, there's one other thought that I obviously failed to communicate into issue due to being more offline than I wanted to:

Technically, those users are able to "click" (hit) a link, also supporting JavaScript links. Thus, a JavaScript link, which directs the Flash movie to start playback, may solve the additional accessibility problem. Shortage: Last time I experimented with this was ten years ago, no idea how that is done today ;)

Battle plan:

1) JS-based feature negotiation + HTML5 audio CAPTCHA callback.

2) Auto-play for Flash movie.

3) JS-based "Play"-link.

sun’s picture

Did we forget about the audio codec disaster? If I parse http://www.happyworm.com/jquery/jplayer/HTML5.Audio.Support/ correctly, then Firefox 3.5 + 3.6 only support Ogg Vorbis and Wave files, Opera only raw Audio() objects (no <audio> tag) and only Wave files...

One of the major reasons to switch to Flash was that the browser extension (runtime) already ensures .mp3 playback support. Mollom would have to deliver a .wav file to work across platforms and independent of codecs, but wave files are entirely uncompressed and thus, very large.

Dave Reid’s picture

Maybe use something like http://mediaelementjs.com/ ?

Everett Zufelt’s picture

@Sun

Correct, there is no * good * codec supported across all browsers for html5 audio. This is the biggest, and most disappointing, issue with html5 audio.

Dries’s picture

Disappointing indeed. I'm not sure why it is taking browsers so long to get audio right? You'd think it is pretty fundamental. Feels like Drupal's image handling -- it took 10 years to get something decent into core. That was long overdue too. ;)

Everett Zufelt’s picture

@Dries

AFAIK it is conflict between licensing on different codex and the licenses that different browser vendors are willing to use with their products.

sun’s picture

http://www.niallkennedy.com/blog/2010/02/html5-video-markup.html contains an excellent summary about progressively enhancing for HTML5 video. AFAIK, the same principles apply to HTML5 audio, so our task at hand is to transform that knowledge into a patch.

Everett Zufelt’s picture

@Sun

Agreed. We can at least do html5 audio w/ mp3 for UAs that support html5/mp3, we can then fallback to Flash for UAs that do not support either html5 audio or the mp3 format. Of course, this presumes that UAs implement the html5 draft correctly.

Is Mollom currently using mp3 as it's audio codec?

Everett Zufelt’s picture

Shelly Powers and Jen Simmons both confirmed for me a feeling I had, browsers will only fall back to non html5 audio content if they do not support html5 audio. So, FF will * likely * not fall back to flash markup within the <audio> ... </audio> tags just because we only offer mp3 as an html5 audio source.

The reasoning, as I understand it, is that UAs only use the fallback content if they ignore, don't recognize, the <audio> element. Otherwise it ignores the fallback content.

Everett Zufelt’s picture

I did a test with the following content:

<h1>html5 audio test</h1>
<p>The following html5 audio player contains only an mp3 source. There is also a single h2 and a single paragraph within the &lt;audio&gt; element as fallback content.</p>

<audio controls="true">
<source src="99.mp3" />
<h2>Fallback</h2>
<p>This is falback content.</p>
</audio>

Results

IE8 / JAWS 11
Reads the fallback content

Safari5 / VoiceOver
Shows player controls and plays the mp3.

Firefox 3.6.10 / NVDA 2010.1 (html5 audio support)
Shows no audio controls and no fallback content.

sun’s picture

Category: feature » task
mgifford’s picture

This would be great, particularly moving ahead to D8.

anthonyR’s picture

reCaptcha has had a keyboard accessible audio solution for a long time. Maybe it would be interesting to see how they approached this?
Sadly reCaptcha changed their audio feedback to a total noisefest so it is no longer a good solution too.

The arguments against html5 audio were posted in 2010. It could be interesting to see what the state of html5 audio is at the moment?

mvc’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Category: task » bug
Priority: Normal » Major

i'm using 7.x-2.x and Everett Zufelt just told me he couldn't create an account on a drupalcamp website i helped build as the mollom audio option was only available via flash. when captchas are used on account creation forms, their accessibility problems render an entire site impossible to use. i'm bumping this to "bug report" and "major" accordingly as several other users are experiencing this problem; i've just marked #1436128 & #768694 as duplicates of this issue.

as much as i'd like to use the tag, the problem Everett mentioned above still exists, according to https://en.wikipedia.org/wiki/HTML5_Audio#Supported_audio_codecs : there is, sadly, no single audio codec supported by all major browsers on all platforms. (we're getting close, though: once FF 24.0 is released, MP3 & AAC will be available for everyone except FF users on OS X.) it's simple enough to work around this by providing multiple options, though. however, even once FF gets around to shipping MP3 & AAC codecs on Mac, we can't assume all users will have the latest, greatest browser. i strongly suggest that we copy recaptcha's example and also provide a link to download the audio in mp3 format to make this as accessible as possible.

users who are both blind and deaf will not be able to use the audio or visual options and so i suggest adding a link to a contact form where they can report their problem and ask an administrator to manually create an account for them, or otherwise intervene as necessary.

regarding localization: the recaptcha audio version consists of a series of numbers preceded by a human voice explaining how to use the captcha. these then need to be localized, so recaptcha's recordings are provided in several languages (fwiw the EN, FR, and ES versions are all completely incomprehensible to me, although i could tell that someone was speaking to me in those languages). however, since mollom uses the NATO phonetic alphabet in theory it should not be necessary to translate the recordings. wikipedia says that the "choice of code words for the letters of the alphabet and for the digits was made after hundreds of thousands of comprehension tests involving 31 nationalities", so barring reports of problems i vote we assume this is good enough for native speakers of languages other than english.

finally, the audio option does not change the field's help text, although this refers explicitly to an image, which makes the CAPTCHA even more confusing than it's supposed to be. also, simply writing "not case sensitive" is not very clear to average users.

on to my suggestions:

1) display the following text only when a visual CAPTCHA is shown:

Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated.

2) render an audio captcha using code like this:

Please listen to the following audio and enter the series of letters indicated. The letters will be read using the NATO phonetic alphabet. For example, if you hear "Alfa" enter the letter "A", and if you hear "Bravo" enter the letter "B". If you can't understand them, submit the form and a new sound will be generated.
<audio controls>
  <source src="captcha.ogg" type="audio/ogg">
  <source src="captcha.mp3" type="audio/mpeg">
  Your browser does not support the audio element. <a href="captcha.mp3">Download sound as MP3.</a>
</audio>

3) display the following message beneath both the visual & audio CAPTCHAs:

Both upper and lower case letters will be accepted. Please <a href="/contact">contact us directly</a> if you are experiencing problems with this CAPTCHA.

mvc’s picture

Title: Investigate trying HTML5's <audio> tag instead of Flash » Accessibility problems with audio CAPTCHA

oops, meant to change the title

eshta’s picture

It seems like using jPlayer could still work to ease a lot of the accessibility problems. While most audio would be served without Flash, the audio that is served with Flash is only the media itself. Controls would be the same for each version and keyboard events can be used as triggers.

eshta’s picture

This issue has become a priority for the Mollom team - yay :-)

While I'm a big fan of jPlayer, the fact that is that it's a jQuery plugin and we're still supporting Drupal 6 (jQuery 1.2.6). That makes me a little nervous. Given that this is an established issue that has been addressed (or attempted) in several large-scale open projects, I don't feel it would make sense to try to maintain a custom solution that reinvents the wheel.

MediaElement does provide the same benefits and does not have the jQuery requirement. There also seems to have been some efforts already to help it along from an accessibility point of view. The existing mediaelement project already uses the libraries project to ensure sharing of the javascript files. This would introduce a dependency on the libraries project. This hasn't been the Mollom module way in the past, but given the huge adoption of this utility project I don't see a problem with it. I wonder if others have different views?

eshta’s picture

I've also spent some time reviewing some of the audio-only libraries. We certainly don't need the extra overhead of a video library. None of them seem to have the traction that jplayer and mediaelement have, however, so they would be unlikely to be already in use on a site.

There are a few good options out there (Audio5JS and SoundJS are two of the frontrunners). We'd be working with a custom UI creation in either of these instances which could be a good or bad thing. The footprints are smaller, but I think it would be harder for implementers to understand and customize. On the other hand, the MediaElement player uses jQuery as well - so we'd likely be making our own interface anyway depending on how well it runs under jQuery 1.2.6.

Of course, all of these do much the installation process for the module much more complex. I'm a little concerned about having a dependency on the libraries project as well as the javascript library download dependency. Given the overwhelming popularity of the libraries module (for good reason) one would think that this is a somewhat commonplace task.

eshta’s picture

Issue summary: View changes
Status: Active » Needs review
FileSize
19.57 KB

So - there is still work to be done here (like adding the actual audio instructions text and fixing some more of the tab navigation issues in Flash) - but what about an approach like this?

Status: Needs review » Needs work

The last submitted patch, 34: mollom.accessibility.34.patch, failed testing.

mvc’s picture

@eshta : i like your approach of trying HTML5, then flash, then providing a download link.

i would suggest writing "Both upper and lower case letters will be accepted" instead of "Not case sensitive" to make the form as clear as possible for non technical folks.

also, i'm concerned about the possible consequences of having multiple conflicting versions of swfobject.js around. normally drupal modules don't ship with copies of external libraries so that they don't have to be responsible for tracking upstream changes. i would suggest just telling people to install it into sites/all/libraries if they want the flash audio player to work; that and the libraries module would then be optional dependencies. if not installed, blind users would still get an HTML5 audio player or a download link, so the site would still be accessible.

with the release of FF 26.0 last month the latest stable version of all major browsers now ship with the MP3 codec on all supported platforms so hopefully the flash option will become less important soon, but in the meantime i think it's a fine idea to provide as many options as reasonably possible.

eshta’s picture

Thanks, mvc. I've been struggling with the external dependencies thing. I agree that we don't want multiple conflicting versions but have been very hesitant on the introduction of dependent modules.

Of course, you are right that this becomes less of an issue each day and becomes less and less likely that the Flash player will even be used. I guess I could run a check:

  • if user has libraries module -> check for swfojbject
  • If not, check in sites/all/libraries/swfobject
  • If there is swfobject then attach it and continue as originally planned.
  • If no swfobject, just add the plain old embed code without version checking (which is what it does now anyway).

I would kind of like to include the download link in the instructions for the audio player. This is for two reasons. The first is to make absolutely sure that we have an accessible fallback. The second is a technically selfish reason.

In order to prevent the flash keyboard trap effect (Flash not allowing users to tab back out of a swf) a common WAI approach is to use SWFFocus. This adds an invisible link before and after the movie to handle tabbing in and out of. One of the problems with this approach is that the keyboard focus shifts to an invisible link before shifting back to the form which is confusing. You can use it with existing focusable elements as well. If we have the download link and the 'switch to verification using image' link, then we can place the download link in the instructions above and the verify beneath and use them as our keyboard access links. Voila - we can tab in and out of the audio player plus have extra insurance that all users can play back the audio captcha.

mvc’s picture

that series of tests makes sense to me!

i've never even heard of the flash keyboard trap effect, but making the download link easier to find sounds good here. here's new proposed audio help text:

Please listen to the following audio and enter the series of letters indicated. The letters will be read using the NATO phonetic alphabet: for example, if you hear "Alpha" enter the letter "A", and if you hear "Bravo" enter the letter "B". Both upper and lower case letters will be accepted. If you can't understand the audio, submit the form and a new test will be generated. If you are having trouble listening to the audio in your browser, you can <a href="captcha.mp3">download the audio as an MP3 file.</a>

eshta’s picture

Status: Needs work » Needs review
FileSize
14.9 KB

So I'm attaching a new patch. This includes the detection for SWFObject and then a manual javascript embed if it isn't found. No more reliance on external JS library ;-)

I also went for a combination change on the instructions. I tried to simplify the last suggestion but still make the download as clear as it was.

Status: Needs review » Needs work

The last submitted patch, 39: mollom.accessibility.39.patch, failed testing.

eshta’s picture

Status: Needs work » Needs review
FileSize
15.22 KB

Patch has a binary file (updated fallback SWF) and I forgot the --full-index flag on my patch. Trying again.

Status: Needs review » Needs work

The last submitted patch, 41: mollom.accessibility.41.patch, failed testing.

The last submitted patch, 41: mollom.accessibility.41.patch, failed testing.

eshta’s picture

Status: Needs work » Needs review
FileSize
24.49 KB

Ugh! Trying again with the binary flag.

Status: Needs review » Needs work

The last submitted patch, 44: mollom.accessibility.44.patch, failed testing.

eshta’s picture

hehe - at least the patch applied this time. Of course there is probably some work to do on the tests as well. I'll do some more work. In the meantime I still welcome suggestions on the approach. I don't really like the javascript embed code when no swfobject is detected. I'd rather just code it in HTML in that case but didn't want to load it needlessly and just hide it.

eshta’s picture

Status: Needs work » Needs review

44: mollom.accessibility.44.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 44: mollom.accessibility.44.patch, failed testing.

eshta’s picture

Status: Needs work » Needs review
FileSize
25.91 KB

Updated test to match updated image alt text.

Status: Needs review » Needs work

The last submitted patch, 49: mollom.accessibility.49.patch, failed testing.

The last submitted patch, 49: mollom.accessibility.49.patch, failed testing.

eshta’s picture

Status: Needs work » Needs review
Related issues: +#2132701: Improve UX of settings page
FileSize
0 bytes

Added the ability to read enabled audio status and respond. The ability to enable/disable audio will be added via settings changes that are in development.

eshta’s picture

Uploading a file with more than 0 bytes this time - although it is nice to see all those test passes, lol.

Status: Needs review » Needs work

The last submitted patch, 53: mollom.accessibility.53.patch, failed testing.

eshta’s picture

Status: Needs work » Needs review
FileSize
16.79 KB

Trying without the binary file and patch.

Status: Needs review » Needs work

The last submitted patch, 55: mollom.accessibility.55.patch, failed testing.

eshta’s picture

Status: Needs work » Needs review
FileSize
26.79 KB

Adding some debug info.

Status: Needs review » Needs work

The last submitted patch, 57: mollom.accessibility.57.patch, failed testing.

eshta’s picture

Status: Needs work » Needs review
FileSize
26.83 KB

Still troubleshooting test failures.

Status: Needs review » Needs work

The last submitted patch, 59: mollom.accessibility.59.patch, failed testing.

eshta’s picture

Status: Needs work » Needs review
FileSize
26.83 KB

More debugging of testbots.

Status: Needs review » Needs work

The last submitted patch, 61: mollom.accessibility.61.patch, failed testing.

eshta’s picture

Status: Needs work » Needs review
FileSize
27.55 KB

more debugging.

eshta’s picture

Still with debugging for the automated test failures, but in the meantime the theming has been split into one template for audio and one template for the image display.

The last submitted patch, 63: mollom.accessibility.63.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 64: mollom.accessibility.64.patch, failed testing.

eshta’s picture

Status: Needs work » Needs review
FileSize
27.45 KB

Getting closer to passing the automated tests.

eshta’s picture

Final patch with debugging from automated tests removed.

eshta’s picture

Version: 7.x-2.x-dev » 6.x-2.x-dev
FileSize
25.64 KB

Providing the patch back-ported to Drupal 6.

eshta’s picture

Status: Needs review » Fixed

This work has been moved into the 7.x-2.x and 6.x-2.x development branches.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

emsearcy’s picture

(If this should be a separate issue, my apologies.)

An early comment said,

I was under the impression voice captcha reads out what the image captcha is? In this case, mollom should not be replacing the image captcha placeholder with the voice captcha player but should just fire the sound file alongside the image captcha?

The new accessibility patch (thankfully) avoids Flash and works better with GUI screen readers (e.g. VoiceOver), but many of our sight-impaired users are using text based browsers which lack the JS functionality to replace the image with the html5 "player". It may look nice to replace the image with the player, but is there not a way to have the sound file "alongside" the image without needing JS? Maybe have both visible initially and use JS to hide the audio one and then use the current click/switch functionality from there?

emsearcy’s picture

Status: Closed (fixed) » Active
eshta’s picture

Status: Active » Closed (fixed)
Related issues: +#2244239: Sound availability in CAPTCHA

Moving the new feature change over to a new ticket rather than keep this old beast going :-)
https://drupal.org/node/2244239

  • Commit 236717d on 7.x-2.x, fbajs, actions by eshta:
    Issue #273964 by eshta: Improve CAPTCHA accessibility and implement...

  • Commit 236717d on 7.x-2.x, fbajs, actions by eshta:
    Issue #273964 by eshta: Improve CAPTCHA accessibility and implement...