Page MenuHomePhabricator

CAPTCHA doesn't work for people with visual impairments
Open, MediumPublic

Assigned To
Authored By
tstarling
Feb 3 2006, 3:40 AM
Referenced Files
F34937927: msg-1280868179-1530.jpg
Jan 31 2022, 3:25 PM
F34937933: photo1642276026.jpeg
Jan 31 2022, 3:25 PM
F34937935: msg-1280868179-1549.jpg
Jan 31 2022, 3:25 PM
F30275840: Screenshot 2019-09-08 at 18.34.33.png
Sep 8 2019, 5:34 PM
Tokens
"Love" token, awarded by DrMel."Heartbreak" token, awarded by Ferdi2005."Love" token, awarded by Daimona."Heartbreak" token, awarded by 1997kB."Heartbreak" token, awarded by Cameron11598."Barnstar" token, awarded by geraki."Heartbreak" token, awarded by Elitre."Heartbreak" token, awarded by Volker_E."Heartbreak" token, awarded by JMinor."Heartbreak" token, awarded by jrbs."Love" token, awarded by Quiddity."Like" token, awarded by OldUser02."Love" token, awarded by Thibaut120094."Love" token, awarded by He7d3r.

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

Discussions and other reports about CAPTCHAs that anybody should be aware of before working on this:

Challenges:

  1. Removing captcha all-together proves that it invites too much abuse for our communities?
  2. External services like Google etc violate our privacy policies
  3. Audio captchas present a language barrier problem (next to the language script barrier of normal captchas)
  4. Writing our own solution is prohibitively expensive (involves solving an open problem in computer science) and captcha weakness for computers might make the whole thing a wasted effort pretty quickly.

Alternatives:

  1. Disable alltogher and deal with the fallout by improving abusefilters etc..
  2. Escalate to some sort of Phone number verification or phone audio message verification (privacy issues and possibly only aggravates the accessibility issue)
  3. Add message to make it clearer where to request manual account creation by existing user
  4. Make a separate 'request an account' queue for these users, for prioritised account-request processing

URL: https://www.w3.org/TR/turingtest/
See Also: T49705: "Can't see the image? Request an account" should be an optional parameter

Details

Reference
bz4845

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Can something please be done about this issue?
It's been 13 years since it was created and Wikimedia's captchas are still as inaccessible as ever.

Can something please be done about this issue?
It's been 13 years since it was created and Wikimedia's captchas are still as inaccessible as ever.

There have been some recent conversations at the WMF regarding this topic, discussing potential paths forward, including the implementation of existing, robust FLOSS options (there aren't many) or perhaps leveraging the services of open and privacy-conscious vendors, e.g. T250227. I'm hopeful that at the very least, some incremental improvement results from these discussions, though I'd note that this is a very complicated issue for Wikimedia in terms of both viable solutions and proper resourcing. Many businesses and orgs have implemented the industry-standard reCaptcha for some time which, while functionally a vast improvement over the existing FancyCaptcha, is a non-starter for Wikimedia due to user privacy concerns.

@sbassett Why haven't audio captchas just been used as a stop-gap measure for the largest language projects? That part just doesn't make sense to me.

In T6845#6781431, @MJL wrote:

@sbassett Why haven't audio captchas just been used as a stop-gap measure for the largest language projects? That part just doesn't make sense to me.

Without leveraging a large commercial product (reCaptcha, hCaptcha, etc.) or finding a robust FLOSS alternative (which doesn't really exist at the moment AFAIK), this would likely be a large and complex project, especially given the existing issues around prioritization and ownership of Wikimedia's current captcha system at the WMF. I don't really mean this as an excuse, but more as a qualifying statement on the reality of the current situation.

In T6845#6781431, @MJL wrote:

@sbassett Why haven't audio captchas just been used as a stop-gap measure for the largest language projects? That part just doesn't make sense to me.

Without leveraging a large commercial product (reCaptcha, hCaptcha, etc.) or finding a robust FLOSS alternative (which doesn't really exist at the moment AFAIK), this would likely be a large and complex project, especially given the existing issues around prioritization and ownership of Wikimedia's current captcha system at the WMF. I don't really mean this as an excuse, but more as a qualifying statement on the reality of the current situation.

I'm talking about the line included in challenges:

  • "Audio captchas present a language barrier problem (next to the language script barrier of normal captchas)"

It seems to imply audio captchas are an option but have been dismissed for this reason. If that's the case, could we not just implement them as a stop-gap measure?

Saying "can we not just" is not helpful.

In T6845#6811866, @MJL wrote:

I'm talking about the line included in challenges:

  • "Audio captchas present a language barrier problem (next to the language script barrier of normal captchas)"

It seems to imply audio captchas are an option but have been dismissed for this reason. If that's the case, could we not just implement them as a stop-gap measure?

There are definitely a few more issues with audio captchas beyond language barriers (which are significant), including their actual efficacy at blocking malicious traffic. This is why service providers such as hCaptcha have actually moved away from this option in favor of other approaches to captcha accessibility. And as I believe @Reedy implied above, implementing audio captchas for Wikimedia production isn't really something that can be completed in week or so - it would be a large effort that likely is not the best solution for improved accessibility at this time.

Silly idea: volunteer-staffed (or contractor-staffed?) phone bank where you call them with your desired username. How many of these do we get, anyway? (Or an estimate, I guess, since by definition we wouldn't know.)

Could the signal vs noise ratio be decreased on this task, please? Thanks.

DrMel raised the priority of this task from Medium to High.May 14 2021, 8:15 PM
DrMel awarded a token.
DrMel added a subscriber: DrMel.

Yes please. We have user group WikiBlind.org connected with fabulous talented problem solvers in Blind and Visually Impaired communities.

Priority was at Medium. I’m new here but took the Bold move of switching it to high and can support/justify as needed. I’ll be at next weekends Hackathon seeking anyone who can help fix this massive gap in inclusivity.

Please message me if this is something you care about. Even if you have very little time, I’d be so grateful to get your perspectives. Dr.Mel.Ganus@gmail.com

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.

In T6845#4856949, @jrbs wrote:

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.

Just read this comment. We can address the “work put aside for this” so it earns the High Importance tag.

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.

The blind community has very savvy experts who can help. It might not have been solved by the sighted communities yet but there are plenty of motivated people ready to help.

Aklapper lowered the priority of this task from High to Medium.May 14 2021, 8:34 PM

@DrMel: You are welcome to increase priority and set yourself as task assignee if you plan to work on fixing this, as the Priority field summarizes and reflects reality and does not cause it. If you're interested in contributing code to fix this, please see How_to_become_a_MediaWiki_hacker - thanks in advance for your help.

DrMel raised the priority of this task from Medium to High.

@DrMel: You are welcome to increase priority and set yourself as task assignee if you plan to work on fixing this, as the Priority field summarizes and reflects reality and does not cause it. If you're interested in contributing code to fix this, please see How_to_become_a_MediaWiki_hacker - thanks in advance for your help.

I’m all in! Happy to take the lead on the problem solving and eager to find help. Raised priority back to High per your comments above.

@DrMel: Could you elaborate on your plans to go forward, code-wise?

@DrMel: Could you elaborate on your plans to go forward, code-wise?

New here so not sure how to answer sufficiently. If someone who has been here longer can do a coaching conversation with me, I’ll be able to give you a real answer.

Simplest answer currently: I’m coFounder and organizer of WikiBlind and we have members around the world with extensive experience across domains. But I don’t know who inside this sighted wiki programmers world is currently concerned enough to help with the problem solving. I can facilitate connecting the dots and getting a sprint+ going to make some sort of headway on this critical problem. Everyone who knows about it is very frustrated it has not been worth solving yet. We’ve got Human Resources available. This shouldn’t be on a backburner.

Anyone here, please let me know if you can help me understand how best to contribute my time/skills? I was a programmer long ago. Worked in Microsoft in 80s. Now much more organizer and problem solver.

In T6845#6840433, @APerson wrote:

Silly idea: volunteer-staffed (or contractor-staffed?) phone bank where you call them with your desired username. How many of these do we get, anyway? (Or an estimate, I guess, since by definition we wouldn't know.)

WikiBlind.org now has admins who can create accounts for anyone who cannot create their own. Need to make alternate signup options “visibly” available in account creation / Captcha point. e.g. “Click here if you are unable to complete this account creation page.” which takes people to page with list of other options.

In T6845#6840433, @APerson wrote:

Silly idea: volunteer-staffed (or contractor-staffed?) phone bank where you call them with your desired username. How many of these do we get, anyway? (Or an estimate, I guess, since by definition we wouldn't know.)

WikiBlind.org now has admins who can create accounts for anyone who cannot create their own. Need to make alternate signup options “visibly” available in account creation / Captcha point. e.g. “Click here if you are unable to complete this account creation page.” which takes people to page with list of other options.

enwiki, for example has https://en.wikipedia.org/wiki/Wikipedia:Request_an_account. But we don't link it on https://en.wikipedia.org/wiki/Special:CreateAccount

Newbie Hackathon Qs: Could someone here let me/us know:

who are the current admins/decision makers for proposed changes to the main account creation pages?

and/or
What’s the process for proposing changes?

Newbie Hackathon Qs: Could someone here let me/us know:

who are the current admins/decision makers for proposed changes to the main account creation pages?

and/or
What’s the process for proposing changes?

The process for proposing changes appears to be:

  • In February of 2006, report on Phabricator that our CAPTCHA system discriminates against blind people.
  • Watch as nothing gets done about the problem for the next fifteen years.

I'm just saying.

@Guy_Macon: If you are not interested in bringing this ticket forward but only would like to share some (understandable) frustration, then I politely suggest that you spend your time somewhere else. Thanks for your understanding.

I do not think that it is possible for anyone to be more " interested in bringing this ticket forward" than I have been.

I work with adaptive technology for the blind and have seen first hand the struggles users who use text-to-speach browsers have with this.

I have followed every suggestion by anyone who has suggested a way to " bring this ticket forward". Nothing has worked.

I have brought this up in every venue that anyone has suggested. No result.

I have contacted legal, multiple CEOs. the board, several individual board members and multiple department heads. Other foundation employees have reached out to me, tried to help, and failed..

I have talked about this on various pages, both foundation and English Wikipedia, but the problem remains.

If you have a specific suggestion that you believe will result in the foundation assigning a budget and personnel to fixing this, let me know and I will follow that suggestion as well.

But if your only advice is "shut up and allow the illegal discrimination against the handicapped to continue for another fifteen years", then I refer you to the reply given in the case Arkell v. Pressdram.

For me, the urgency was reduced somewhat when I tested a screen reader with a captcha-breaking browser extension, which I found very easily. I used this one but there are plenty of others around. I think the experience with that browser extension installed was actually better than what sighted people experience. It was very fast, and there was no need to retype the solution. A captcha which can be trivially broken with OCR is probably better for accessibility than an audio captcha (an often suggested alternative).

I've always said that we should just disable the captcha and deal with the consequences, and I've tried to demonstrate that our captcha provides only token protection against spam. The main obstacle to that is the Wikipedia community which seems to have a lot more faith in the captcha than I do.

For me, the urgency was reduced somewhat when I tested a screen reader with a captcha-breaking browser extension, which I found very easily. I used this one but there are plenty of others around. I think the experience with that browser extension installed was actually better than what sighted people experience. It was very fast, and there was no need to retype the solution. A captcha which can be trivially broken with OCR is probably better for accessibility than an audio captcha (an often suggested alternative).

This has to be asked, though: should people without disabilities be asked to install browser extensions to use Wikipedia properly (edit with any links or create accounts)? I think treating this issue as less urgent just because there are ways for a subset of disabled people to get around it is really misguided. We would not treat it the same if it affected, say, everyone in Global South (or, even better, Global North), which is an argument for why we should not treat it differently just because there are some hacks available to make this work.

@DrMel Thanks for taking the lead on this! I'm a MediaWiki developer and would be happy to spend some time on this topic. It might be helpful if WikiBlind users could document signup processes which have worked well for them, for example email verification, etc.

@tstarling I like your suggestion to remove the captcha entirely, it's a very flimsy barrier against spam and very likely does more harm than good.

Repeating a point from a comment above, we can potentially build a system similar to "recaptcha", by using the cookies left on a user's browser as a reader of Wiki*edia. This sort of test can filter most users into a low or high risk category. For the low-risk users, we simply let them create an account. For higher-risk users (for example, those who are clearing cookies and creating multiple accounts from the same IP) we can present a captcha.

Hi team, I've recently handled a VRT ticket (Ticket#2021123010001086) on this issue, and gained consent from the customer to share their thoughts in what I hope is a useful testimony to further inform decision making here. @awight, if you're unsuccessful with getting feedback from WikiBlind users, I'm sure this customer would be happy to share more specific thoughts on +/- of any proposed systems or to provide examples that work well.

"In case you're unaware, blind people access the internet using a fairly advanced category of software called screen-readers. Most computers and phones come with one now.

Wikipedia has a security check to keep out bots when creating an account (better known as a CAPTCHA.) This visual challenge completely shuts out anyone using the computer nonvisually: Since the screen-reader is interpreting the information on-screen, and it is a computer program, it's fooled by the same security check that fools bots.

On almost every other website that exists today, there's an audio option available. Instead of showing characters, it reads numbers with an overlay of distracting background that will fool computers while remaining audible to humans. While this does still pose a problem for deaf users, it is a viable alternative for any other person who has trouble with the visual version.

I can't stress the "almost every website" part enough; this is almost as standard as the CAPTCHA itself now. Websites which don't contain it are very much the minority-especially well-known ones like Wikipedia. There is a process by which I can request an account and have it approved in some number of days, but quite honestly, this feels a little like having to ask someone to carry me up the stairs because nobody put in a ramp. There are standard automation processes that have made it possible for me to do this independently since the very early 2000s, and the fact that I can't create my own account in 2022 feels really discouraging and a bit like Wikipedia has just forgotten about part of its user base. By now there are so many solutions to this problem that not having one in-place can only be deliberate, and that flies in the face of web accessibility.

By the way, the reason I want to create an account is because I've been donating to Wikipedia for a year or so, and I'm getting pop-ups on my phone and computer now. I got an e-mail recently telling me that I could log in with an account if I want the donation prompt to go away, and so I tried to create one and found the process completely unachievable on my phone or computer. This is not me pulling the donor card; I think that's petty and not worth the relatively tiny amount I do donate; but I do feel uncomfortable giving money to a site that can't do this most basic thing to accommodate the millions of blind and visually-impaired people around the world."

"This is actually a super thoughtful and thorough response; thank you. It tells me the issue is more complicated than even I realized, and that the developers are aware of accessibility challenges and privacy concerns.

Having used HCaptcha, I can confirm that it would work well for most people's needs and would probably be the simplest to implement. Many people are concerned with the need to provide an e-mail address, but I believe HCaptcha is actively working on multiple solutions that will make this unnecessary. The only situation where it becomes problematic is on mobile devices. Since users bypass the CAPTCHA by installing a cookie into their browser, it's not possible to do the same with a mobile app. Solutions could include adding a phone number verifier as an additional option, or finding a way to verify that creation requests come from the mobile app and simply removing the CAPTCHA altogether in that case. (I don't know the technical specifics of how to do this unfortunately.)

It is sad that what I like to call "analysis paralysis" has stalled this for all of 15 years; at this point anything would be better than nothing. But I also really understand the need to get it right. I'm more than happy to test out any and all of the FLOSS options out there and provide feedback on them. It would be valuable way beyond this single situation."

@Guy_Macon: I asked you to add constructive comments. See https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette for guidance. Thanks.

Request denied.

We have had fifteen years of "constructive comments" and yet we are still discriminating against the handicapped in direct violation of the Americans with Disabilities Act.

At this point the only actual constructive comment I have for you is to once again clearly explain what needs to be done to fix this problem.

[1] The WMF must give an assignment to a specific paid employee or paid consultant to fix the problem.

[2] The WMF must create a budget for fixing the problem.

[3] The WMF must set a schedule for fixing the problem.

Once we have the above, we can all pitch in and support whoever it is who's job it is to fix this problem.

Is someone in WMF management who is reading this prepared to take the above steps at this time?

Is anyone who is reading this prepared to forward this to someone in the WMF who has the authority to take the above steps?

Or are we going to keep talking about how to fix this for another decade or two?

Because WMF management not only refuses to assign a developer with a budget and a deadline to fixing this but refuses to discuss it, we are left with Yet Another Volunteer Willing To Work On This.

The question then becomes "does this volunteer have the authority to make actual changes to fix this? Do they know a person who has that authority who is willing to at least consider making any changes they suggest?"

Once someone is actually given the job of fixing this, a good place to start would be to consider replacing our current CAPCHA system with something better that is open source and suitable for running on our servers.

For example, would this be suitable?

Negative Captcha [ https://github.com/subwindow/negative-captcha ]

Also, here is an overview of some alternatives. [ https://www.smashingmagazine.com/2011/03/in-search-of-the-perfect-captcha/ ]

“Spam is not the user’s problem; it is the problem of the business that is providing the website. It is arrogant and lazy to try and push the problem onto a website’s visitors.”

— Tim Kadlec, Death To CAPTCHAs [ https://timkadlec.com/2011/01/death-to-captchas/ ]

I've always said that we should just disable the captcha and deal with the consequences, and I've tried to demonstrate that our captcha provides only token protection against spam.

+1. Since there's no team tagged on this task, I've added Readers-Web-Backlog and Platform Engineering, although I don't know if this falls into their areas of work. If it doesn't, perhaps their respective product/engineering management folks could find team(s) that are able or interested to work on this, or reply with an updated response on how WMF will or will not deal with this task.

Clearly no team wants any part in this, so much should be clear by now. We all know each team is understaffed. It also doesn't help their KPIs to take this on, so there is 0 incentive to get involved (exactly why the current KPI system is so bad for the more marginal yet costly problems).

However any change would likely be helped by having at least a modicum of statistics to base a decision on.

  1. How often is the Login/Create account captcha triggered
  2. how often is it properly resolved/how many account creations does it block
  3. Can we correlate some blocked account creations with even an rough estimate of bots vs humans ?

Is there any way this can be recovered from (event) logging ? I assume we have some data of at least the login flow (although perhaps not all public in grafana, for security BEANS reasons.)

If we do not have this, we probably should just wing it, send out a community update and switch $wgCaptchaTriggers['createaccount'] = false; $wgCaptchaTriggers['badlogin'] = false; (maybe even all of them $wmgEnableCaptcha['enwiki'] = false) and just SEE what the community says. It's been 7 years since we last tested that (for half an hour) and we don't even know what the community thought of that....
It's a config setting, we can switch it back if there are too many complaints after a week or so. Finding out any other way just seems cost prohibitive, so let's take a chance. Worst that can happen is en.wp is a bit more upset than they already are all the time, maybe an emergency config setting deploy is required at some point, but that's nothing compared to the chance of potentially fixing this issue. Tim seems reasonably sure of it and that's good enough in my book for a longer test.

If ppl get upset for a week, we know we will need an alternative and at least we know a team has to work on it if we want this fixed. If they get upset for 2 days and then the abusefilters catch up, then we don't have a problem and we can try it on all the wikis (which I personally think is the bigger problem, as they don't have as many abuse countermeasures in place as en.wp)

We do have some statistics in https://grafana.wikimedia.org/d/000000370/captcha-failure-rates?orgId=1 and https://grafana.wikimedia.org/d/000000004/authentication-metrics?orgId=1. The CAPTCHA failure rate is consistently at ~30%, or 100-200 per hour (rolling average). The number of attempted CAPTCHAs per hour (500-600), however, is significantly smaller than the number of displayed CAPTCHAs (which is noisy but consistently in the tens of thousands range). That would seem to imply that replacing the CAPTCHA with a "Bots go away" sign would be nearly as effective. That, or the data on displayed CAPTCHA is not being collected correctly.

MediaWiki.org test is interesting in that it can provide a potential bandaid solution until we get to something better: disable captcha on one of the projects with their agreement, ideally the one that is both language-neutral and most monitored/abuse-filtered like Meta-Wiki, and add a message before the form (in the software for all Wikimedia projects) saying something like Register here if you cannot use visual captcha (link opens in new tab) (should be in wiki language, of course). It would mean more spam registrations getting through on Meta or another project, but it would also mean that until this whole issue gets solved properly, actual people from different Wikimedia projects would still gain the ability to register easier.

There is, of course, another issue of displaying captcha on link additions, but it’s a bit easier to manage there given that you can, say, still add links without https:// part if you’re a good actor (and we can probably display a message like that if people fail link captcha).

...perhaps their respective product/engineering management folks could...

Has anyone in WMF management ever responded to any communication on this issue? Emails, noticeboard discussions, mailing list discussion, and phabricator comments all go into a black hole.

This my reply to the email I got from Phabricator - hadn’t realized it’d post to the group…

Hi Guy et al!

I’m happy to be resurfacing and so grateful for your time and passion for getting this stuff figured out.

Im better in conversations then in long emails - would it be possible to talk with you online with voice or a text chat?

Ive poured a lot of time into creating wikiBlind.org with some amazing other peeps - and its been a struggle as you so well know.

Id love to connect!

Want to pick a time on my calendar?

calendly.com/drmel

with MuReMuPu (mutual respect, mutual purpose),

Mel

ps - we are having a zoom party on 1/15 for wikipedia day and head of afb.org will be joining us. We would love to include you and everyone else who cares about accessibility and inclusivity!

~~~~
Dr Mel Ganus, EdD, MBA, ADD

"Working toward the greatest good for the greatest number."

Who here could meet up in a zoom this weekend (Jan 8-9) to discuss possibilities? There are ways to move forward - takes some version of collaboration to persist through the obstacles. I’ve got a Zoom room available and a flexible schedule all weekend.

On January 15, we are putting together a wikiBlind wikipedia birthday party. We have so many blind and visually impaired peeps who have been reading Wikipedia for years and who want to help, but have never been invited. Could you join us to help figure out how to be more inclusive?

Having spent a lot of time getting my own head around why this still an unsolved problem can I ask for help with the simplest of the low-tech solutions?

Anyone trying to create an account who has trouble with the recpt h should be easily able to submit a request for an account in some other manner. We already have that in our account creation process - but it takes more than 5 minutes of persistence and screen reader time to get to the button that allows someone to submit the request.

Could you here reading this now try going through the steps of account creation from an incognito browser window? Perhaps on a phone? Start the stop watch and see how long it takes to get to alternatives for requesting an account. How could we shorten the steps? Who has the authority to make it easier to request an account?

We do, it's right under the captcha input field.

I've always said that we should just disable the captcha and deal with the consequences, and I've tried to demonstrate that our captcha provides only token protection against spam. The main obstacle to that is the Wikipedia community which seems to have a lot more faith in the captcha than I do.

A token protection might still catch the stupidest 99% of spambots for all we know. Attempts to disable the captcha resulted in a spam flood; the last one was a long time ago though. We could try again if we can get one wiki to volunteer.

If we do not have this, we probably should just wing it, send out a community update and switch $wgCaptchaTriggers['createaccount'] = false; $wgCaptchaTriggers['badlogin'] = false;

Um... let's not do that. Unless the person who does it also volunteers to clean up all the spam that might result. Editors are doing spambot cleanup in their free time, they should not be signed up for extra work without their consent.

The number of attempted CAPTCHAs per hour (500-600), however, is significantly smaller than the number of displayed CAPTCHAs (which is noisy but consistently in the tens of thousands range). That would seem to imply that replacing the CAPTCHA with a "Bots go away" sign would be nearly as effective. That, or the data on displayed CAPTCHA is not being collected correctly.

Or it's from bots which don't actually want to register (e.g. spiders which don't respect robots.txt but don't POST), or spambots which request lots of captchas until they find one they can guess (although as Tim pointed out our captcha is weak enough that that seems unlikely).

We could try replacing FancyCaptcha with QuestyCaptcha with some trivial question ("Type 'human'") though and see how well that works.

In T6845#7594407, @stjn wrote:

MediaWiki.org test is interesting in that it can provide a potential bandaid solution until we get to something better

User accounts are global, so removing captcha on one site creates a backdoor for others as well. Then again, any spammer who cares enough to notice that the captcha can be circumvented by signing up on another wiki has probably long circumvented it via more direct methods, anyway.

I asked for feedback on mediawiki.org.

@Samwalton9 is this topic in scope for the Moderator Tools team? Spambots can consume significant amounts of moderator time (see T241921: Fix Wikimedia captchas for some numbers and links).

(It seems to me @DrMel does not have the wherewithal, despite good intentions, to make progress on this, and therefore that it would be better to unassign the task and restore the previous priority, to better reflect actual status.)

In T6845#7608088, @Ijon wrote:

(It seems to me @DrMel does not have the wherewithal, despite good intentions, to make progress on this, and therefore that it would be better to unassign the task and restore the previous priority, to better reflect actual status.)

Wow. How to respond…. Thank you for suggesting that Im not capable of making progress on this by myself. Totally true. But the priority should not be reduced again.

As the primary organizer of wikiblind.org and co-organizer of wikimedia accessibility group, I am willing to stay here and in the conversation until these issues are solved. If anyone more active in Phabricator circle would be willing to take the lead on this, please do - I/we want to support progress however we can.

@ljon if you see my wherewithal lacking, please explain what i can do to make more progress here?

Aklapper lowered the priority of this task from High to Medium.Jan 10 2022, 10:25 AM

@Ijon @Aklapper Just to be clear, it looks to me like DrMel is offering to make contact with users who are experts in accessibility, and has given this task more productive attention than anybody to date. Assigning the task to DrMel is comparable to assigning it to a project manager while the specifications are drafted. The missing "wherewithal" to complete this task is for an organization to dedicate software engineering staff to the project. If activity stalls again, of course we can unassign.

@DrMel This business of setting task "priority" according to budgeted resources is a common source of frustration, I wanted to point to a resource explaining how priorities are set. According to this page, our convention is to use priority not in its common sense, but to describe whether work is "immanent". For example, a task is marked High priority when "Someone is working or planning to work on this task soon".

It's nearly a year since I last commented asking if something could be done, and it's disappointing to see that we're in the same place. I am blind and use a screen reader so I know first hand how frustrating this is. I'm also a member of WikiBlind.
With that said, at least there's been a couple of suggestions of solutions.
I'm not sure if Negative Captcha would work, because screen readers probably would not be able to distinguish between the fields we're supposed to fill in and the ones for the bots. Screen readers read webpages by using the document object model and other things, probably the same way bots do. Maybe someone more knowledgable than me on how screen readers work could chip in.
An alternative to captcha I've seen simply asks you to fill in EG the 8th word on a linked page, and the number changes each time the page is refreshed. Go to the OpenMPT Wiki registration page to check it out. It's also powered by MediaWiki.
There's probably a ton of reasons why this is not a good idea, but it's the next best thing accessibility wise I've seen next to the 'I'm not a robot' tick boxes, which incidentally someone actually got a robot to click. So every captcha thing will have some kind of bot that will crack it. The priority should be making stuff easier to use for us users.
I hope that by this time next year something will be done about this, instead of us going round in circles. It's been too long.

In T6845#7606894, @Tgr wrote:

I've always said that we should just disable the captcha and deal with the consequences, and I've tried to demonstrate that our captcha provides only token protection against spam. The main obstacle to that is the Wikipedia community which seems to have a lot more faith in the captcha than I do.

A token protection might still catch the stupidest 99% of spambots for all we know. Attempts to disable the captcha resulted in a spam flood; the last one was a long time ago though. We could try again if we can get one wiki to volunteer.

Honestly, at this point, +1 to disabling FancyCaptcha if it doesn't result in disastrous amounts of spam on various projects. Perhaps this could be tested somewhat clandestinely and in a phased manner on smaller projects, with config changes to PS.php and members of the Security-Team and global stewards monitoring and rolling back if the results prove untenable. FancyCaptcha's image-based captchas are nearly-defeatable with out-of-the-box tesseract and trivially-defeatable by any number of browser extensions (as noted above) and dozens of captcha-solving services with questionable reputations and affordable pricing. If disabling FancyCaptcha buys us vastly increased accessibility without an insurmountable increase in spam on the projects, it's certainly worth the trade. Especially until some more robust system can be implemented, if that's even realistic or worthwhile.

Maybe at least A/B test disabling FancyCaptcha, in line with what sbassett says above? I'd love to see some movement on this.

OK, we discussed this in the a11y usergroup a bit more over the last week and I realised that not all of these problems have to be solved via changing the captcha system. So what is primary blocking here is the captcha indeed. But when the captcha displays, it presents the "Can't see the image, request an account" option. and it is TERRIBLE !

msg-1280868179-1530.jpg (790×331 px, 26 KB)

Because everyone clicks request an account for any problem they encounter (because humans) when trying to create an account, the en.wp community has built a wall of text to keep people out, completely inconveniencing people who have actual trouble reading the captcha.

photo1642276026.jpeg (1×960 px, 247 KB)

msg-1280868179-1549.jpg (1×960 px, 205 KB)

this page gets about a 1000 page views a day, and you have to find a button at the bottom of the page, to continue. This button funnels you into the ACC wizard. Here you have to go through multiple pages, until finally you get a link to ACC requests, hosted on wmflabs (where all previously gathered context from the ACC wizard gets lost, instead of prefiled into the ACC dialog.

Easy improvements:

  1. Route ppl immediately into the ACC wizard from this entry point in the create account screen, and only drop them back to Wikipedia:Request_an_account as a fallback.
  2. Improve accounts.wmflabs.org to receive collected info from ACC wizard via query params, saving everyone time
  3. Move "accessibility" into the first page of ACC wizard.

So this is another idea I had, but it might not be possible to do;

  1. The message for "create account" is MediaWiki:createacct-imgcaptcha-help
  2. but this is globally overridden with wikimedia-createacct-imgcaptcha-help
  3. We could set that to use https://accounts.wmflabs.org/?page=createaccount&domain={{SERVERNAME}}&lang={{CONTENTLANGUAGE}}
  4. We add basic translations to the tool for these new steps
  5. Then have account.wmflabs.org do a preselection on accessibility vs. other problems.
  6. If not-accessibility problems, redirect them back to https://domain/wiki/MediaWiki:createacct-captcha-help-url. (we'd need a domain whitelist)
  7. Have the ACC team deal with all the accessibility requests for all wikis and all languages.

Now that is going to be controversial of course. It is going to create a lot of work for English wikipedia, but maybe its worth exploring.

As an example, I have setup https://test2.wikipedia.org/wiki/Special:CreateAccount with a direct link to accounts.wmflabs.org (open in private browser window to make sure you get the captcha) and just try comparing that with en.wikipedia.org and following the path there to get started with an actual account request. You can see that the difference is huge.