Page MenuHomePhabricator

CAPTCHA doesn't work for blind people
Open, NormalPublic

Description

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."


Version: unspecified
Severity: normal
URL: http://www.w3.org/TR/2005/NOTE-turingtest-20051123/
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47705

Details

Reference
bz4845

Event Timeline

bzimport raised the priority of this task from to Low.
bzimport set Reference to bz4845.
bzimport added a subscriber: Unknown Object (MLST).
tstarling created this task.Feb 3 2006, 3:40 AM
brion added a comment.Feb 3 2006, 10:16 AM

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.

omniplex wrote:

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 ***

brion added a comment.Aug 8 2007, 5:14 PM
  • Bug 10340 has been marked as a duplicate of this bug. ***
brion added a comment.Dec 6 2007, 7:22 PM
  • Bug 12218 has been marked as a duplicate of this bug. ***

mike.lifeguard+bugs wrote:

(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.

jamestneill wrote:

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

sumanah wrote:

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.

pajz added a comment.Sep 13 2012, 10:45 PM

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 :).)

gmaxwell wrote:

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.

wmf.amgine3691 wrote:

(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.

sumanah wrote:

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.

Restricted Application added subscribers: Florian, Aklapper. · View Herald TranscriptDec 29 2015, 2:55 PM
Base added a subscriber: Base.Dec 8 2016, 1:07 AM
jrbs added a subscriber: jrbs.Feb 20 2017, 9:13 PM
jrbs added a comment.Feb 20 2017, 9:15 PM

This task is now 11 years old - is there any appetite to make movement here? A blind potential user has now emailed into OTRS asking for advice, and it'd be good to allow volunteers to respond positively.

jrbs added a subscriber: dpatrick.

Pinging @dpatrick as this probably now falls under Security's remit as well. (The new project tag may not be accurate, do please edit ruthlessly.)

This doesn't just effect addition of external links, it also prevents new users from registering, requiring them to use ACC to request an account. Is this still being looked at as an issue?

TheDJ added a comment.Jul 10 2017, 7:58 PM

@Cameron11598 There is no one currently assigned to this, so no one is taking it upon him to fix this at this moment. It's also not something that any team at the foundation is responsible for, so it's not likely to be prioritized from that end.

Unfortunately it's not an easy thing to fix :(

@TheDJ Well thats disappointing but thanks for the information. :(

TheDJ added a comment.Jul 11 2017, 8:34 AM

Another person requesting about audio captcha's
https://en.wikipedia.org/w/index.php?title=Wikipedia:Teahouse&oldid=790035476#Audio_alternative_for_CAPTCHA

I was thinking about this last night. Using Google etc, is of course 'evil' and not allowed by any of our standards. At the same time, we don't have the resources to rebuild what Google has already built. But perhaps we could offer a Google Captcha as a secondary option ? So that when you encounter our captcha, there is a button to take you to a google Captcha for those who cannot read/use our captcha ? It's not ideal, but it's better than not fixing this for another 11 years.

Elitre added a subscriber: Elitre.Aug 25 2017, 10:52 AM
Restricted Application added a subscriber: jeblad. · View Herald TranscriptAug 25 2017, 10:52 AM

WCAG 2.0 SC 1.1.1 requires non-text CAPTCHAs to have "alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities"

Ejs-80 added a subscriber: Ejs-80.Dec 21 2018, 10:39 PM
Cameron11598 added a comment.EditedJan 2 2019, 9:40 PM

Just trying to nudge this to see if it is being worked on yet? On a side note its been 12 years and this issue still hasn't really been addressed...

Nick raised the priority of this task from Low to Normal.Jan 3 2019, 11:27 AM
Nick added a subscriber: Nick.Jan 3 2019, 11:30 AM

I've raised the priority of this task from Low to Normal - clearly fixing an issue which is preventing users with sight issues from registering and thereby participating in our projects is not a 'low' priority task in any conceivable situation.

On a related note, given WMF has now started to abandon the old and highly restrictive policy of only ever using free and open source software, alternative CAPTCHA services can now be considered.

On a related note, given WMF has now started to abandon the old and highly restrictive policy of only ever using free and open source software, alternative CAPTCHA services can now be considered.

[citation needed]

On a related note, recaptcha isn't just a concern about FOSS, there are also concerns about privacy and security of allowing a third party to run JS on our sites.

Would giving the user the ability to switch to a math based captcha if they are unable to read the regular captcha be a possible solution?

TheDJ added a comment.EditedJan 4 2019, 9:54 AM

One of the alternatives I have seen suggested that I think might be feasible, is a captcha fallback using verification via phone number.

That would require the user entering his international phone number, then WMF using a commercial service like twillio and using their text to speech to sent a code to a user in a phone call (English only), which the user then needs to enter in another textfield for verification. That would be less private (but only for a very specific group of people). It would allow us to block automated services if needed and twillio also has Answering machine detection.

That involves clearing a commercial service within WMF for this specific use case (as well as its recurring monthly costs), privacy policy adaptations for the phone number data (at a 3rd party), a new extension for making the api requests and verifying the codes, keeping a blacklist of phone numbers that have been abusive, rate limiting, db changes, security review etc, testing it etc.. aka easily 3-4 months with several involved resources and teams.

Would giving the user the ability to switch to a math based captcha if they are unable to read the regular captcha be a possible solution?

Computers are good at math. So no.

WereSpielChequers raised the priority of this task from Normal to High.Jan 5 2019, 5:07 PM

I have corrected the priority to high. Obviously something that excludes such a large group of people needs to be fixed as a matter of priority. It shouldn’t be all that difficult to do a workaround such as MzMcbride suggested. If everyone who verifies an email address was exempted from such capchas then not only do we solve a major disability barrier, we also fix a problem that is a barrier for all new Wikipedians.

jrbs lowered the priority of this task from High to Normal.EditedJan 5 2019, 5:30 PM

I have corrected the priority to high. Obviously something that excludes such a large group of people needs to be fixed as a matter of priority. It shouldn’t be all that difficult to do a workaround such as MzMcbride suggested. If everyone who verifies an email address was exempted from such capchas then not only do we solve a major disability barrier, we also fix a problem that is a barrier for all new Wikipedians.

Please note that "priority" on Phabricator does not mean "importance", it just reflects how tasks are being handled by the teams in question. See this for more information: https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels

As such, I'm lowering this back to Normal, since no work has been committed for this. While I agree this is an important task to work on, marking this as "high" is misleading as it implies work has been put aside for it, which it has not.

So the question is why has work not been put aside to fix an issue of recognised high importance that will, 13 years after first being raised, resolve an issue that results in us discriminating against people who are (in many jurisdictions) a legally protected minority?

So the question is why has work not been put aside to fix an issue of recognised high importance that will, 13 years after first being raised, resolve an issue that results in us discriminating against people who are (in many jurisdictions) a legally protected minority?

Because it basically involves solving an open problem in computer science which despite more than 13 years of people attempting to solve it, there aren't really any good solutions to.

Okay then another possible (temporary solution) ACC's request an account is where we occasionally shunt requests for those using screen readers; could we make that more prominent and perhaps provide an OTRS queue so that ACC folks can create the accounts quicker or a specialized queue for ACC so those requests so they can be prioritized in some way? For the record the current oldest request at ACC is from 2018-11-19 and there are over 1800 pending requested accounts.

I'm just spitballing ideas here because what we currently have isn't equitable nor does it really work from a pragmatic point of view.

an open problem in computer science which despite more than 13 years of people attempting to solve it, there aren't really any good solutions to.

(For those more interested in audio captchas, Google's audio captcha can be circumvented with a ~90% success rate: http://uncaptcha.cs.umd.edu/ )

@Nick: A reference for your statement above is still welcome.

Would it be possible to at least provide directions on how users can register for an account? Below are some of the methods that have been listed

  • EN.Wikipedia - Refers to ACC
  • META.Wikimedia - https://meta.wikimedia.org/wiki/Help:Captcha ( Unfortunately this may inconvenience users with limited vision or using text-based or speech-based browsers. At the moment we do not have an audio alternative available. Please contact the site administrators for assistance if this is unexpectedly preventing you from making legitimate actions. ) Note: provides no way to contact administrators.
  • Commons.Wikimedia - Same as Meta
  • Wikidata - Same as Meta but actually provides a link to the list of admins
  • De.Wikipeida - Referral to OTRS team
  • Wiktionary - Same as Wikidata
  • WikiNews - Sends them to IRC
  • Wikiversity - Sends to a list of deletions for a non-existant page ( https://en.wikiversity.org/wiki/Wikiversity:Request_an_account )
  • Wikisource - Same as Wikiversity ( https://en.wikisource.org/wiki/Wikisource:Request_an_account )
  • Wikibooks - Sends you to the equivalent of WP:AN
  • Simple.Wikipedia - Sends you to a help desk page

Some of these are decent (my personal favorites being En.Wikipedia, Wikinews and De.Wikipedia. But there is no reason there shouldn't be directions on Wikiversity or Wikisourse on who to contact. :/

I didn't go through every project but would it be possible to find out how many projects actually don't have a help page for this?

jrbs awarded a token.Mon, May 6, 6:32 PM