Last modified: 2014-11-17 10:35:14 UTC
No convenient method is offered to allow blind people to submit external links to Wikimedia sites. As per the W3C recommendation: "An explicitly inaccessible access control mechanism should not be promoted as a solution, especially when other systems exist that are not only more accessible, but may be more effective, as well. It is strongly recommended that smaller sites adopt spam filtering and/or heuristic checks in place of CAPTCHA."
The edit captcha is triggered heuristically; currently this is a crude test for added non-local URLs by unregistered and recently created accounts (with a manual switch to engage for all edits in emergency situations), but it could be refined further to 'suspicious-looking' URLs, graylists, other suspicious edit patterns, etc. Ideally, getting hit with a captcha should be a relatively rare event.
It also doesn't work with Netscape 4.x (a browser supporting PNG or at least some PNG). And it's impossible to load it for view with an external tool, it has a "load once" (instead of twice) restriction. I come to the point where I'd know how to get the relevant captcha for the first time with Lynx, but of course it insists on a cookie, and I've no clue about Lynx' cookies, normally I never use Lynx.
*** This bug has been marked as a duplicate of bug 10340 ***
*** Bug 10340 has been marked as a duplicate of this bug. ***
*** Bug 12218 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > The edit captcha is triggered heuristically; currently this is a crude test for > added > non-local URLs by unregistered and recently created accounts (with a manual > switch to > engage for all edits in emergency situations), but it could be refined further > to > 'suspicious-looking' URLs, graylists, other suspicious edit patterns, etc. > > Ideally, getting hit with a captcha should be a relatively rare event. > I love the idea of a greylist (& note that "suspicious edit patterns" is covered by bug 18110). However, creating an account requires solving a captcha - that's not targeted at all.
Graphic captchas are inaccessible to screenreader users (e.g., JAWS). Easy-to-implement audio captchas are available. [http://en.wikiversity.org/w/index.php?title=Wikiversity%3AColloquium&action=historysubmit&diff=580431&oldid=580415]
(In reply to comment #7) > Graphic captchas are inaccessible to screenreader users (e.g., JAWS). > Easy-to-implement audio captchas are available. > [http://en.wikiversity.org/w/index.php?title=Wikiversity%3AColloquium&action=historysubmit&diff=580431&oldid=580415] Yet they don't mention any, I would be guessing they are talking about ReCaptcha which has already been discussed and turned down since it would be residing on a third party server (googles in this case afaik).
Captchas with visual verification are unsolvable problems for some groups of users on the internet. They often prevent the users (which also can be customers) from using online services or contact/comment forms. The Carnegie Mellon University provides a [http://recaptcha.net/plugins/mediawiki/ MediaWiki extension] for reCAPTCHA, which also includes an alternative audio CAPTCHA. Unfortunately, this solution can't be used for Wikipedia/MediaWiki at the moment. Why? Please see this [http://lists.wikimedia.org/pipermail/wikitech-l/2008-April/037354.html post] on the Wikitech-l mailing list for example. Brion, the chief MediaWiki developer: "The only thing stopping us from having an audio captcha is that nobody's put the work into implementing it yet." [http://lists.wikimedia.org/pipermail/wikitech-l/2008-April/037351.html wikitech-l/2008-April] It would be great if the reCAPTCHA developers or someone else could provide an additional extension just for an audio solution. This would make many blind and visually impaired users around the world very happy and could make them more independent of seeing help. [http://blog.blindaccessjournal.com/search/label/CAPTCHA Blind Access Journal], entries with tag CAPTCHA
How much knowledge would someone have to have in order to implement this fix? I ask so I can suggest this task to appropriate volunteers.
An audio captcha? I would consider it a domain specific problem. Knowledge about mediawiki isn't a requisite. The glue could be added by others if needed. I think the two questions to do that are: a) How to generate the sound? (voice file of project foo? a prerecorded set of digits which are presented randomly?) b) Which kind of distortion would be applied to the sound? A naive approach of "concatenating" digits from a set is probably relatively easy (just indagate a bit about sound formats), but that would alo be trivial to undo. Maybe we should try to involve people working in that field, such as Theora, festival or CMU Sphinx.
if you want to work with prerecorded sound files (and not with generated sound files by a computer "AI") then the Wikipedia/media project might help to record the files (and this with national/native speakers).
(In reply to comment #10) > How much knowledge would someone have to have in order to implement this fix? > I ask so I can suggest this task to appropriate volunteers. In order to make an Audio Captcha extension it would require a developer and a audio file editor, along with couple of speakers. According to the research "Evaluating Existing Audio Captchas and an Interface Optimized for Non-Visual Use" (http://www.annacavender.com/downloads/captchachi09.pdf) controlling playback directly in the answer box with keyboard shortcuts would increase the success rate of blind users by 59% on Audio Captchas. So someone capable of making such an interface would be great. The audio file editor needs to be highly experienced. Additionally it would require a few speakers and it has already been pointed out that the Wikipedia projects can help with that.
One user (himself visually-impaired) pointed out to us at OTRS that it might be better to use something similar to what they use here http://www.creatiffi.de/modeschmuck-gaestebuch/gaestebuch.html#footer (section "Spam-Schutz"), i.e. small tasks of the form "The number 55 minus the number 1" (in this case based on the implementation in the CMS http://www.papoo.de/). He also noted that audio captchas are often hard to understand, so he would favor such an option which also might be easier to implement. (Given that no mention of anything apart from audio captchas has been made here so far, I'm just adding this on his behalf :).)
That kind of text arithmetic 'captcha' is the default captcha in mediawiki. It's not used on Wikimedia sites because it's trivially scripted by bots and so it's ineffective once someone actually tries. http://textcaptcha.com/ has a similar thing, but the questions it asks are quite repetitive and I'm skeptical that it would be effective either.
It seems like Facebook and Twitter rely on a valid e-mail address instead of using a CAPTCHA. I wonder if that would be a possible resolution to this bug.
(In reply to comment #16) > It seems like Facebook and Twitter rely on a valid e-mail address instead of > using a CAPTCHA. I wonder if that would be a possible resolution to this bug. No. reCaptcha and whatever it is being used by yahoo and hotmail have a better than 10% resolve rate by some spambots - which means they have access to (and use) valid e-mail addresses.
Discussions and other reports about CAPTCHAs that anybody should be aware of before working on this: http://lists.wikimedia.org/pipermail/wikitech-l/2008-April/037309.html http://lists.wikimedia.org/pipermail/wikitech-l/2013-January/065818.html https://bugzilla.wikimedia.org/show_bug.cgi?id=32695
Adding a few people to cc who are interested in helping with accessibility issues - see https://www.mediawiki.org/wiki/Accessibility#People_and_organizations_working_on_MediaWiki_accessibility for more.
