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. [email protected]

In T6845#4856936, @WereSpielChequers 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.

In T6845#4856949, @jrbs wrote:

In T6845#4856935, @WereSpielChequers 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.

In T6845#4857904, @Bawolff wrote:

In T6845#4856993, @Thryduulf wrote:

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.

In T6845#7089069, @Aklapper wrote:

@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?

In T6845#7089146, @Aklapper wrote:

@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#7089183, @DrMel wrote:

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?

In T6845#7089749, @DrMel wrote:

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.

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

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.

In T6845#7091447, @tstarling wrote:

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

In T6845#7091225, @Aklapper wrote:

@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/ ]

In T6845#7091447, @tstarling 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.

+1. Since there's no team tagged on this task, I've added Web-Team-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).

In T6845#7593870, @kostajh wrote:

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

In T6845#7089194, @Reedy wrote:

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

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

In T6845#7091447, @tstarling 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.

In T6845#7594294, @TheDJ wrote:

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.

In T6845#7594351, @AntiCompositeNumber wrote:

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?

@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:

In T6845#7091447, @tstarling 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.

I've split out the captcha disabling discussion to T299629: Test disabling the captcha on some Wikimedia wikis.

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 !

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.

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.

I'm currently working with a professor who got stuck on this while trying to create their account.

Screen reader users routinely expect an audio CAPTCHA option these days, and for account creation, the request account option (per TheDJ above) is not an acceptable user experience (and not many people will make it through that). Even if they are an incomplete solution because of language issues, in my opinion, adding audio CAPTCHA support would be a clear improvement over the current situation.

In T6845#7664178, @TheDJ wrote:

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.

Added a similar link to https://ru.wikipedia.org/wiki/MediaWiki:Createacct-imgcaptcha-help
Hopefully it's alright that some requests to ACC will not be in English (even though I noted that the form is in English). I don’t think that it is acceptable for any wiki to be inaccessible to people with vision problems, so that seems like the only solution at the moment while the WMF is slacking.

A quote from journalist Shira Ovide:

"While CAPTCHA can be tough for humans, they aren’t so effective at proving humanness. Artificial intelligence has solved many types of CAPTCHA for years. Businesses also pay armies of workers to fill out CAPTCHA in bulk. The more people and machines find ways to get around CAPTCHA, the harder companies have made them. This creates a doom loop of irritation..."

https://www.washingtonpost.com/technology/2023/07/25/captchas-hate-privacy-pass/

Please consider this recent (22 July 2023) academic paper on this:

An Empirical Study & Evaluation of Modern CAPTCHAs

https://arxiv.org/abs/2307.12108
https://arxiv.org/pdf/2307.12108
https://www.semanticscholar.org/paper/An-Empirical-Study-%26-Evaluation-of-Modern-CAPTCHAs-Searles-Nakatsuka/cf3f0924c7d78b11c01ea77579d66870327506f6

The study found that when they paid people to solve CAPCHAs, 30% abandoned
the task prior to completion, that all types of CAPTCHAS take longer for older participants. This raises whether, as established above, we are not only discriminating against the handicapped, we are also discriminating against the elderly.

Also, please consider this article in New Scientist:

Bots are better at beating 'are you a robot?' tests than humans are: The use of CAPTCHA tests to prove that website users are human and not bots might come under scrutiny given research showing that bots complete them faster and more accurately than we do

https://www.newscientist.com/article/2384228-bots-are-better-at-beating-are-you-a-robot-tests-than-humans-are/

This article discusses the above research, pointing out that

"When humans solved distorted text CAPTCHA tests [the kind Wikipedia requires you to solve when creating a new account], they took between 9 and 15 seconds and achieved accuracy of only 50 to 84 per cent. Bots taking the same test completed it in less than a second with 99.8 per cent accuracy."

Before anyone fires up their flamethrower in response to the above, please consider the fact that this issue was first reported on Feb 3 2006, and we still have no way for blind people to create an account on Wikipedia. There is no WMF employee or consultant who has been assigned the job of fixing this, nor is there any budget or deadline. What we have been doing for the last 17 years is clearly not working.

Another reason to consider removing the Captcha is that they are no longer accessibility compliant per the latest release of WCAG (2.2).

For the record, they were never accessibility compliant anyway. It is impossible to fill the captcha as a vision-impaired user.

In T6845#9232350, @stjn wrote:

For the record, they were never accessibility compliant anyway. It is impossible to fill the captcha as a vision-impaired user.

Yes, but with the Universal Code of Conduct, this is now not just something wanted by the community or at least those of us in it who care about disability rights wants. It is a glaring breach of the WMF's own Universal Code of Conduct. I've criticised some bits of the UCOC, for starters I think we should desysop admins who develop dementia, and while I'm tolerant of precocious editors, I can see why some will vote against admin candidates who they think are under 18. But there are other bits of the UCOC that I'm keen on, and that includes not discriminating against the disabled. My hope is that if we make a big deal of this as a breach of UCOC we will get some attention from the WMF.

In T6845#9231257, @JScherer-WMF wrote:

Another reason to consider removing the Captcha is that they are no longer accessibility compliant per the latest release of WCAG (2.2).

Not really? The changes are about authentication, where we (mostly) don't use a captcha.

The relevant bit for CAPTCHAs is https://www.w3.org/TR/WCAG22/#ref-for-dfn-captcha-1 which we do fail but which isn't new to 2.2.

Again I say, this issue was first reported on Feb 3 2006, and we still have no way for blind people to create an account on Wikipedia. There is no WMF employee or consultant who has been assigned the job of fixing this, nor is there any budget or deadline. What we have been doing for the last 18 years is clearly not working.

So, what are our options other than continuing to comment here a couple of times a year to no effect?

Post an RfC? Try to get this covered by the press? Contact individual board members and ask them to act?

I fear that if we don't do something to get this moving someone will sue the Wikimedia Foundation for violating Title III of the Americans with Disabilities Act of 1990 as happened in https://en.wikipedia.org/wiki/National_Federation_of_the_Blind_v._Target_Corp. I don't think anyone here want to see that happen.

In T6845#8120297, @Ragesoss wrote:

Even if they are an incomplete solution because of language issues, in my opinion, adding audio CAPTCHA support would be a clear improvement over the current situation.

It would be pretty easy to make something that has the appearance of an audio captcha. As long as defeating off-the-shelf speech recognition software is not a goal, it's pretty straightforward. The visual captcha can be trivially solved by OCR, so it would make sense to have a corresponding audio captcha which can be trivially solved by speech recognition.

I have an idea for an audio captcha. I wrote it up at T354234 and made a demo.

The problem with audio captchas is that for deafblind people they will not be accessible.

In the UK, this ticket would now be old enough to drink and still nothing has been done.