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

Happy belated 19th birthday to this ticket. I hope it being moved means something's being done.

As part of T250227, the WMF is evaluating hCaptcha (a commercial "modern" captcha service) as a replacement for the current distorted text challenge captchas. The expectation is that most users will not see a visible challenge, and will only have to check a checkbox. However, this assumption may not hold true for screen reader users.

hCaptcha provides a cookie-based tool for bypassing the captcha, but this has several limitations, including but not limited to privacy and arbitrary denials. This would improve the situation somewhat for users that are already enrolled in the program, and may improve things for users on smaller wikis that do not have an existing account creation process.

It is unlikely that a move to hCaptcha would solve all captcha-related accessibility issues.

In T6845#10555864, @AntiCompositeNumber wrote:

As part of T250227, the WMF is evaluating hCaptcha (a commercial "modern" captcha service) as a replacement for the current distorted text challenge captchas. The expectation is that most users will not see a visible challenge, and will only have to check a checkbox. However, this assumption may not hold true for screen reader users.

hCaptcha provides a cookie-based tool for bypassing the captcha, but this has several limitations, including but not limited to privacy and arbitrary denials. This would improve the situation somewhat for users that are already enrolled in the program, and may improve things for users on smaller wikis that do not have an existing account creation process.

It is unlikely that a move to hCaptcha would solve all captcha-related accessibility issues.

Thanks for the summary, @AntiCompositeNumber. For those who are interested, https://www.hcaptcha.com/accessibility describes in more detail hCaptcha's accessibility accommodations. I agree that a potential move to hCaptcha would not solve all the issues, but I think it will be progress in the right direction.

Comment by a frustrated Wikipedian.
en.wikipedia.org has recently put a captcha on its login page. This has blocked many editors with an assistive reader from editing Wikipedia any more (unless you are lucky today and your IP address is not currently rangeblocked).
May I suggest options to send a voice transcript of the letters either by immediate media playback or phone. The phone solution works well for me where I need 2FA (My landline delivers all texts as voice anyway). A third option would be to send the letters to the email account registered for the account.
By offering multiple response options, more users will be able to work at least one of them.

@Steelpillow Thank you for your comment. CAPTCHA-on-login was implemented via T379178: Support captcha as part of login flow (not just on "badlogin"). We will either make this less restrictive or switch it off. I'll post a bit later.

In T6845#10686319, @kostajh wrote:

@Steelpillow Thank you for your comment. CAPTCHA-on-login was implemented via T379178: Support captcha as part of login flow (not just on "badlogin"). We will either make this less restrictive or switch it off. I'll post a bit later.

We're switching this off now and will re-enable in case of emergency, or after we've implemented a pathway for editors using an assistive reader who are editing from IPs flagged in the IP reputation database we consult.

Note that, starting from 28 June 2025 (so just last week), services such as Wikipedia I think are formally required to comply with the European Accessibility Act (EAA):
https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/union-equality-strategy-rights-persons-disabilities-2021-2030/european-accessibility-act_en

From what I know, WCAG 2.1 Level AA is referenced in a related directive. I know that many large service providers, such as banks, are now changing everything from using simpler language in documents to modifying or reviewing their forms. So maybe you could put more priority into this.

Hey @Nux, thanks for the comment! We are indeed working to improve our captchas (T250227). We believe the new system will address a number of security, accessibility, and compliance issues. Right now, we are preparing a trial, a project page, and the related announcements. I will get back to you within 2–3 weeks. Thanks!

Re further announcements: I've just discovered this relevant post on Wikimedia's blog, Diff, which mentions this task: https://diff.wikimedia.org/2025/09/02/better-detecting-bots-and-replacing-our-captcha/

In T6845#11143533, @Graham87 wrote:

Re further announcements: I've just discovered this relevant post on Wikimedia's blog, Diff, which mentions this task: https://diff.wikimedia.org/2025/09/02/better-detecting-bots-and-replacing-our-captcha/

@Graham87 thanks for linking this here. There is also the project plan documentation here: https://www.mediawiki.org/wiki/Product_Safety_and_Integrity/Anti-abuse_signals/hCaptcha

To note here, hCaptcha is now running in production for Special:CreateAccount on English Wikipedia, test2wiki, and several other production wikis. We encourage folks on this thread interested in improving accessibility to try it out. For example, we'd be interested in hearing what the screen reader experience is like. test2wiki is likely the most appropriate place for testing that actually creates new accounts.

Importantly, hCaptcha is running in 99.9% invisible mode in these settings, and so most of the time no challenge will appear. I don't have great advice for how to force the challenge to show, and the rules for when it shows are deliberately opaque. Informally, I understand the use of Tor Browser to raise the chances significantly, though for specialized browsing tools that may not be very helpful.

While we would like to see that the actual challenges themselves are more manageable for screen readers and similar (there are text-based challenges) when presented, a big part of the usability/accessibility goal here is to challenge users far less in the first place. That said, if some types of devices more commonly cause a challenge to appear, that is also helpful to learn.

In T6845#11300179, @EMill-WMF wrote:

We encourage folks on this thread interested in improving accessibility to try it out. For example, we'd be interested in hearing what the screen reader experience is like. test2wiki is likely the most appropriate place for testing that actually creates new accounts.

(courtesy link; test2wiki being https://test2.wikipedia.org/wiki/Special:CreateAccount)