I Want to Love Linux. It Doesn’t Love Me Back: Post 1 – Built for Control, But Not for People — fireborn
I Want to Love Linux. It Doesn’t Love Me Back: Post 1 – Built for Control, But Not for People — fireborn
Insightful article. I have to confess I never realized the accessibility situation was this bad.
I also want to highlight this excerpt from the comments:
Making things accessible isn't hard technically. But it requires coordination and people to care about it enough to work on it at the expense of other features. If [I] developed an application on a team and said I had 'one security guy that works on that stuff as long as it doesn't interfere with the rest of our work' I'd be dragged over the coals and have my project forked by the public.
But with accessibility? There's really no sense of priority or urgency despite it being broken for years and not putting much effort in to fixing it.
i think a good example is text size. My eyesight isnt horrible but it isnt great either so some small text can be hard to read for me. But in gnome in accessibility there is just a toggle for "large text" so i can either make all text fucking massive, or have it be normal. Other than that the most i can do is try to change specific font settings and fiddle with it constantly for each application lol. This could be fixed by just having a slider instead of a toggle in gnomes text accessibility options and letting you choose between a few different sizes.
I was always wondering why there's no real audio-based interface for blind people, instead of trying to describe what's on the screen. Have this ever been tried out?
Programming for accessibility is one of these things that I always fascinated me, and it makes me sad that support for it no longer matters for a lot of software developers. Maybe it's something I am going to try to do? Is there any documentation where to start with that?
This is devastating and truly an indictment on the "code it yourself" mentality that is leaving accessibility as an exercise for the user... which is the opposite of accessibility.
This should be shared far and wide.
Woah their partner, major software developers have been having similar issues with accessibility for decades now. For instance the ability for the blind to deal with Windows if it crashes or errors out is pretty much non-existent.
https://nfb.org/sites/default/files/images/nfb/publications/bm/bm15/bm1504/bm150403.htm
Google isn't much better breaking accessability in the name of protecting content.
So I will have to respectfully tell you to get off your high horse.
I understand the problem of "code it yourself". But if they won't code it themselves, and it ought to exist, who has to? Everything that is provided is provided for free and with love and passion. If something is lacking in that there are only a few options. Including code it yourself or pay someone to code it for you. The only reason you get anything at all is because of the "code it yourself" attitude of the people who developed the software in the first place, as well as their willingness to share it.
I have a web music player that I've developed, and while it was never really intended to be used by others, I thought I had generally followed accessibility best practices. After using it for about two years, I realized that I never even implemented keyboard shortcuts. 🫠
Which is to say, one shouldn't assume devs to know what they're doing. At some point, I'm also just a user and I use software like everyone else does, meaning I pick out a path that works for me and then I hardly look left and right from there.
Features not being tested when you don't use them yourself, that happens with any feature. But it's much worse for UI features, because those are difficult to automate tests for. And accessibility is in an even worse spot, because it necessarily opens up a separate path, which is going to be invisible to me as a user, so it gets covered by neither automated tests nor by me just using the software.
I have to go out of my way to test accessibility, which means I have to be aware that a change I'm making might introduce a regression. That's genuinely how lots of amateur developers work, which is probably the best explanation why accessibility support is often so amateur-ish...
Good fucking lord:
Just stay positive and keep going as hard as that can be sometimes it’s just like anything else the more of it you do the better you get.
"Built for control, but not for people" sums up so well what's wrong with the developer-user disconnect among many in the free software space.
I think it has to do with neurodivergence, where a lot of people who use their computers 12+ hours a day can't fathom that there are other people who don't do the same.
This is a really well written article. It's unfortunate that this person has to deal with all these issues.
I suspect the reason that both MATE and the Debian installer have good accessibility support is because their codebases are quite old. In general, it seems like older software is more likely to have better accessibility support than newer software.
Accessibility should be something that's built into software from the very beginning, but I totally understand that not all developers have time for it or properly understand it. It's unfortunate.
One thing I've had troubles with when trying to implement accessibility is in web dev. There's so many attribute tags and I think a few different software based standards as well? I'm not entirely sure. The documentation on it felt a bit hard to follow and implement. Then I'm not sure how to go about testing it fully either without having those proprietary softwares either. I'm on an all Linux machine and the only accessibility software I know of is Orca and it's so and so last time I tried it.
While I slowly figure that out however I make sure to follow tag recommendations and keep things in sections, only one h1 tag per page, descriptive and short alt tags, and so forth. At least that helps a tiny bit.
Web is a bit easier than native since the browsers handle all the platform-specific details across all common platforms, and you mostly just have to follow some guidelines that aren't overly technical or arcane. Some examples:
<label>tags to label for all your<input>s,altattributes on all images,titleattributes where appropriate (e.g. on<table>s to describe the data contained inside the table), etc.If you use Firefox, its developer tools have an "Accessibility" tab that can audit for common issues - things like missing labels on checkboxes and radio buttons, colours that don't meet WCAG contrast ratio requirements, etc.
It's a good time to learn more about building accessible sites and apps given it's becoming a legal requirement in some jurisdictions. For example, the European Accessibility Act (EAA) goes into effect later this year, and it mandates that sites and mobile apps for various industries (like ecommerce, airlines and other transport, media streaming, social media, banks, and some others) meet accessibility guidelines.
It's probably worth spinning up a Windows VM to test in NVDA. It's one of the most popular screen readers and probably the most popular open-source one, but only works on Windows since it deeply hooks into the Microsoft Speech API, accessibility APIs, and and other Windows APIs.