In my last post I talked about our move from Github to Codeberg. I mostly write code, not blog posts, but there's an important follow up to that.
I've been busy recently working on a new FEC library based on RaptorQ. This would be my first project that's never been on Github, and my first new project published on Codeberg. I uploaded it and tooted about it on Mastodon. Codeberg even shared our toot - Github certainly never did that!
This is what it feels like to be part of a community. Sharing. Working together towards common goals. We were feeling pretty good about choosing Codeberg.
But the thing is, it's not when things are going well that you find out someone's character, but when things are going badly. How do they react when the chips are down? How do they take criticism? How does a company respond to support requests? How does that project respond to bug reports?
In a mad flurry of prerelease testing Coverity turned up an odd sign-extension bug that didn't make any sense to me and I asked my teammate for help. After some poking around in the assembly to figure out how multiplying two unsigned integers was causing sign extension, he had a fix. This would be his first commit to the new project, and first interaction with Codeberg.
Or it would be, if he could create an account. Unfortunately Codeberg uses a visual only CAPTCHA, so our happy coding train comes to a sudden halt.
CAPTCHAs are a well-known accessibility problem. Best to avoid them at all if possible. If you really need some kind of bot prevention, there are lots of ways to handle this. If you insist on using a CAPTCHA, make sure it is accessible to all. There are W3C and various government guidelines about this.
The great thing is, we hadn't chosen some proprietary system run by a faceless corporation - we'd chosen Codeberg! So this would be an easy fix. So I tooted (politely) about it on Masto:
Yes, I could have raised a ticket, but I find accessibility issues are generally best dealt with in public view, otherwise they tend to languish in bug trackers. They're kind of like the opposite of security bugs.
That post triggered a flurry of action, but sadly not from Codeberg. It turned out that this issue and many other accessibility concerns were raised over a year ago, with no progress. Over the next few days there was a lot of discussion on Masto, on Codeberg's bug tracker and in a Matrix accessibility room.
There have been a number of suggestions for technical solutions from the community, including an offer from a FOSS project that makes a CAPTCHA alternative.
Unfortunately this isn't, and never was, a technical issue. The problem here is one of attitude towards accessibility issues.
The first step towards fixing any problem is acknowledging that it exists. So far Codeberg refuse to do that, and so all the passive aggressive "PRs welcome" are just deflections. Send a PR for what? Which of the many solutions we've proposed do you want implemented? Or should we all waste time with PRs that will be rejected or ignored?
For a feature request for something non-core to the project, asking for a PR is fine. When someone reports an accessibility or other human rights based issue, you have a moral (and in many cases legal) requirement to do something about it. You. Not the affected users.
Sending a code PR isn't a minor thing, even for a developer. For anyone not actively working on the project, they need to first fork the repo, download it, set up the build environment which probably means spinning up virtual machine. Then they need to, from a standing start, grok your code, find the right place to make the change, test it, read through your submission guidelines etc. and then they can send a PR.
A developer on the project will already have the code checked out and knows what to do. For a tiny fix it's just ludicrous to ask someone not part of the team to drop their own jobs to do yours. And to waste time doing all that when the project won't even acknowledge the problem? Come on.
If Codeberg seriously need technical help with this, acknowledge the problem, commit to fixing it and ask for help.
But, wait, hasn't already Codeberg offered an accessible alternative by emailing them?
No. That isn't acceptable. That's like putting a set of steps in front of a wheel chair and then putting up a sign that says "Holler for help!". You've taken away that person's autonomy by making them beg for help. That is not "access on an equal basis".
When you set CAPTCHA such that a visually-impaired person fails to prove that they are human to a computer, how do you think that feels? Would you be frustrated? Angry? Now imagine you have a similar negative accessibility experience with 8 out of 10 websites you try to interact with. Every day. You're going to need a bigger swear jar.
Codeberg are a legal entity in the EU that have chosen to provide a service. For free. Good on them!
That the service is free does not absolve them of the responsibility to provide that service on "on an equal basis" to all.
Why make all this fuss about Codeberg? Why not pick on some big faceless corp?
Precisely for the reason Codeberg aren't some billion dollar faceless corp. They're a small community run FOSS site and they can be better. The good guys need to be held to a higher standard. I like Codeberg.
And we have tilted already at the windmills of Github, Mozilla, Google etc. Sometimes they even fix something. For a bit.
What hope have we got for fixing the rest of the Internet if we can't even fix a FOSS site like Codeberg?
Accessibility is hard. Believe me, I know. Mistakes are fine, but effectively saying WONTFIX on something as easy to solve as the CAPTCHA issue is not.
Previous (Give Up Github) Next (What3Words)
2022-07-19