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?
Comment | File | Size | Author |
---|---|---|---|
#69 | mollom.accessibility.backport.69.patch | 25.64 KB | eshta |
#68 | mollom.accessibility.68.patch | 27.06 KB | eshta |
#67 | mollom.accessibility.67.patch | 27.45 KB | eshta |
#64 | mollom.accessibility.64.patch | 27.45 KB | eshta |
#63 | mollom.accessibility.63.patch | 27.55 KB | eshta |
Comments
Comment #1
BioALIEN CreditAttribution: BioALIEN commentedI 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?
Comment #2
Gurpartap Singh CreditAttribution: Gurpartap Singh commented+1!
Comment #3
Boletus CreditAttribution: Boletus commentedI disabled the Mollom module. All in all, the usability of it was not good enough.
Comment #4
Dave ReidUgh... 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.
Comment #5
Dave ReidAudio captcha is now a flash plugin, which works a lot better for everyone.
Comment #6
Dries CreditAttribution: Dries commentedWish we could use the
<audio>
tag in HTML5. :)Comment #7
Dave ReidI 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.
Comment #8
Dries CreditAttribution: Dries commentedSee 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.Comment #9
Dave ReidMoving to the HTML5 request as postponed.
Comment #10
Dave ReidApparently all we'd need to do is
if (!!document.createElement('audio').canPlayType)
Comment #11
Everett Zufelt CreditAttribution: Everett Zufelt commentedtagging
Comment #12
sunIf 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.
Comment #13
sun.
Comment #14
MacRonin CreditAttribution: MacRonin commented@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.
Comment #15
aspilicious CreditAttribution: aspilicious commentedI 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)
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.
Comment #16
sunI 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.
Comment #17
sunDid 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.
Comment #18
Dave ReidMaybe use something like http://mediaelementjs.com/ ?
Comment #19
Everett Zufelt CreditAttribution: Everett Zufelt commented@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.
Comment #20
Dries CreditAttribution: Dries commentedDisappointing 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. ;)
Comment #21
Everett Zufelt CreditAttribution: Everett Zufelt commented@Dries
AFAIK it is conflict between licensing on different codex and the licenses that different browser vendors are willing to use with their products.
Comment #22
sunhttp://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.
Comment #23
Everett Zufelt CreditAttribution: Everett Zufelt commented@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?
Comment #24
Everett Zufelt CreditAttribution: Everett Zufelt commentedShelly 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.Comment #25
Everett Zufelt CreditAttribution: Everett Zufelt commentedI did a test with the following content:
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.
Comment #26
sunComment #27
mgiffordThis would be great, particularly moving ahead to D8.
Comment #28
anthonyR CreditAttribution: anthonyR commentedreCaptcha 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?
Comment #29
mvci'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:
2) render an audio captcha using code like this:
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.
Comment #30
mvcoops, meant to change the title
Comment #31
eshta CreditAttribution: eshta commentedIt 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.
Comment #32
eshta CreditAttribution: eshta commentedThis 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?
Comment #33
eshta CreditAttribution: eshta commentedI'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.
Comment #34
eshta CreditAttribution: eshta commentedSo - 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?
Comment #36
mvc@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.
Comment #37
eshta CreditAttribution: eshta commentedThanks, 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:
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.
Comment #38
mvcthat 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>
Comment #39
eshta CreditAttribution: eshta commentedSo 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.
Comment #41
eshta CreditAttribution: eshta commentedPatch has a binary file (updated fallback SWF) and I forgot the --full-index flag on my patch. Trying again.
Comment #44
eshta CreditAttribution: eshta commentedUgh! Trying again with the binary flag.
Comment #46
eshta CreditAttribution: eshta commentedhehe - 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.
Comment #47
eshta CreditAttribution: eshta commented44: mollom.accessibility.44.patch queued for re-testing.
Comment #49
eshta CreditAttribution: eshta commentedUpdated test to match updated image alt text.
Comment #52
eshta CreditAttribution: eshta commentedAdded 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.
Comment #53
eshta CreditAttribution: eshta commentedUploading a file with more than 0 bytes this time - although it is nice to see all those test passes, lol.
Comment #55
eshta CreditAttribution: eshta commentedTrying without the binary file and patch.
Comment #57
eshta CreditAttribution: eshta commentedAdding some debug info.
Comment #59
eshta CreditAttribution: eshta commentedStill troubleshooting test failures.
Comment #61
eshta CreditAttribution: eshta commentedMore debugging of testbots.
Comment #63
eshta CreditAttribution: eshta commentedmore debugging.
Comment #64
eshta CreditAttribution: eshta commentedStill 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.
Comment #67
eshta CreditAttribution: eshta commentedGetting closer to passing the automated tests.
Comment #68
eshta CreditAttribution: eshta commentedFinal patch with debugging from automated tests removed.
Comment #69
eshta CreditAttribution: eshta commentedProviding the patch back-ported to Drupal 6.
Comment #70
eshta CreditAttribution: eshta commentedThis work has been moved into the 7.x-2.x and 6.x-2.x development branches.
Comment #72
emsearcy CreditAttribution: emsearcy commented(If this should be a separate issue, my apologies.)
An early comment said,
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?
Comment #73
emsearcy CreditAttribution: emsearcy commentedComment #74
eshta CreditAttribution: eshta commentedMoving the new feature change over to a new ticket rather than keep this old beast going :-)
https://drupal.org/node/2244239