The tricky thing with these "unofficial" distros is that they are generally maintained by either a single individual or a small group of people.
This is true for many accessibility projects actually (game mods, third-party UIs for inaccessible services/platforms, etc.).
These are generally really meant as short-term patches while the problem gets fixed, except ... the problem often doesn't get fixed because the platforms in question figure it's been solved now and they don't need to care about it anymore.
Accessibility really only works when it's an ongoing, first-class process within an app/platform's design, and we can absolutely do that; the standards and guidelines have existed for decades. People working in cybersecurity, localization, general UX should recognize this song and dance, which is amusing because a lot of the tools of those trades have atrocious accessibility and require all sorts of workarounds, ask me how I know.
People just ... aren't including it in this way, which means people like myself (screen reader user and accessibility professional) essentially have to keep reminding people that we exist and that it's kinda shitty to keep forgetting about that fact or to decide the least amount of effort possible (LLM, unpaid volunteer, send in a PR LMAO) is enough to cater to people who have very real, very annoying and very constant UX issues we either crash into or crash through on literally an hourly basis.
It's because adding new shiny features is fun and adding accessibility is boring, and most people in the free software world are there to have fun. That's also why bugs are always forgotten while people keep piling new features.
I also think it's partly because adding accessibile interfaces is hard.
If you are not visually impaired then designing then when designing a visual interface for an application you are more-or-less designing for yourself. You know how to use visual interfaces, so it is relatively easy for you to evaluate whether you've done a good job.
Most people do not know how to use a screenreader, so if you're designing for a screenreader then it's going to be much harder for you to test the interface and evaluate whether it's actually usable by it's target audience.
I'd also love to see more educational resources on this topic. Not just "use this attribute/role for this use case", but "this is how using a screenreader works. This is an example of a good workflow . this is an example of bad workflow". There's tons of material out there for visual design, but I haven't come accross nearly so much for other interfaces.
It’s not a free and open source issue, it’s a general issue in product development.
Whereas in free software, people develop apps to have fun, in business product development, teams always try to ship a feature that is the highest leverage, and making the app work well with screen readers is usually not the highest leverage item, unfortunately.
Here's an interview (in Czech) with Vojta, the main (only) developer. There might be follow up articles discussing specific issues he's facing as user and as a developer.
I'm glad to see things like this get built. I hate to admit it but I rarely consider impaired usecases when building things. I wonder how technology is changing this usecase lately both on the user end and the design end. (I know, AI) I imagine an LLM could help discover inadequate UI and build alternative workflows into products more easily.
Whispir is a much better TTS than almost anything else. However, when it gets it wrong, oh boy does it get it wrong.
For everything else? Not really. JS thrashing the DOM is as much a pain as ever. Using ico files instead of either emoji or... Text... Makes UIs painful and inconsistent.
Everyone using Electron and its broken [0] accessibility, including core Windows features...
These aren't things that can be reasoned away with an LLM. An interface is not just text - its a reasoned nodegraph. And when I'm blind (comes and goes), I need the nodegraph. Not an image of the screen reinterpreted.
I find it very hard to know what to do to follow best practice. For example the biggest UK charity for blind people make social media posts about the importance of text descriptions and alt tags that break what I thought was good practice (they duplicate text in post and alt tag) and they seem to encourage this.
I imagine this is where LLMs could really help actually. LLMs are natively surfing the web now so I suspect LLM descriptions of sites or even having them re-render a site in a more usable way is becoming much more possible.
'Honestly this is a people problem more than a tech problem. We have the tech. We're just not using it.
I'd say LLMs COULD make it easier to implement accessibility, it also couldn't, always a coinflip with those, but I'd say LLMs actually succeeding is probably unlikely given how much shitty code is probably in its training data :P
The tricky thing with these "unofficial" distros is that they are generally maintained by either a single individual or a small group of people.
This is true for many accessibility projects actually (game mods, third-party UIs for inaccessible services/platforms, etc.). These are generally really meant as short-term patches while the problem gets fixed, except ... the problem often doesn't get fixed because the platforms in question figure it's been solved now and they don't need to care about it anymore.
Accessibility really only works when it's an ongoing, first-class process within an app/platform's design, and we can absolutely do that; the standards and guidelines have existed for decades. People working in cybersecurity, localization, general UX should recognize this song and dance, which is amusing because a lot of the tools of those trades have atrocious accessibility and require all sorts of workarounds, ask me how I know.
People just ... aren't including it in this way, which means people like myself (screen reader user and accessibility professional) essentially have to keep reminding people that we exist and that it's kinda shitty to keep forgetting about that fact or to decide the least amount of effort possible (LLM, unpaid volunteer, send in a PR LMAO) is enough to cater to people who have very real, very annoying and very constant UX issues we either crash into or crash through on literally an hourly basis.
The readme addresses this problem comprehensively. "The ultimate vision of Vojtux is "NO VOJTUX NEEDED!" because Fedora will be fully accessible."
It's not really a distro in the usual sense, more a minimal customisation of Fedora.
It's because adding new shiny features is fun and adding accessibility is boring, and most people in the free software world are there to have fun. That's also why bugs are always forgotten while people keep piling new features.
> adding accessibility is boring
I also think it's partly because adding accessibile interfaces is hard.
If you are not visually impaired then designing then when designing a visual interface for an application you are more-or-less designing for yourself. You know how to use visual interfaces, so it is relatively easy for you to evaluate whether you've done a good job.
Most people do not know how to use a screenreader, so if you're designing for a screenreader then it's going to be much harder for you to test the interface and evaluate whether it's actually usable by it's target audience.
I'd also love to see more educational resources on this topic. Not just "use this attribute/role for this use case", but "this is how using a screenreader works. This is an example of a good workflow . this is an example of bad workflow". There's tons of material out there for visual design, but I haven't come accross nearly so much for other interfaces.
It’s not a free and open source issue, it’s a general issue in product development.
Whereas in free software, people develop apps to have fun, in business product development, teams always try to ship a feature that is the highest leverage, and making the app work well with screen readers is usually not the highest leverage item, unfortunately.
seems like the real places to make durable changes would be in the desktop environment software packages (kde, gnome, etc)?
although it also seems useful to figure out which third party packages and default settings make sense.
Are there "official" Linux distributions?
Maybe "unofficial Fedora version" would have been more deserving of the "unofficial" specification.
GUIX is the official GNU Linux Distribution
That is not an answer to the question. There are no "official linux distros".
1 reply →
Does GNU know about that?
https://www.gnu.org/distros/distros.html
Here's an interview (in Czech) with Vojta, the main (only) developer. There might be follow up articles discussing specific issues he's facing as user and as a developer.
https://www.root.cz/clanky/pristupnost-se-musi-stat-obcanem-...
I'm glad to see things like this get built. I hate to admit it but I rarely consider impaired usecases when building things. I wonder how technology is changing this usecase lately both on the user end and the design end. (I know, AI) I imagine an LLM could help discover inadequate UI and build alternative workflows into products more easily.
Whispir is a much better TTS than almost anything else. However, when it gets it wrong, oh boy does it get it wrong.
For everything else? Not really. JS thrashing the DOM is as much a pain as ever. Using ico files instead of either emoji or... Text... Makes UIs painful and inconsistent.
Everyone using Electron and its broken [0] accessibility, including core Windows features...
These aren't things that can be reasoned away with an LLM. An interface is not just text - its a reasoned nodegraph. And when I'm blind (comes and goes), I need the nodegraph. Not an image of the screen reinterpreted.
[0] https://github.com/electron/electron/issues/45856
I find it very hard to know what to do to follow best practice. For example the biggest UK charity for blind people make social media posts about the importance of text descriptions and alt tags that break what I thought was good practice (they duplicate text in post and alt tag) and they seem to encourage this.
6 replies →
I imagine this is where LLMs could really help actually. LLMs are natively surfing the web now so I suspect LLM descriptions of sites or even having them re-render a site in a more usable way is becoming much more possible.
3 replies →
'Honestly this is a people problem more than a tech problem. We have the tech. We're just not using it.
I'd say LLMs COULD make it easier to implement accessibility, it also couldn't, always a coinflip with those, but I'd say LLMs actually succeeding is probably unlikely given how much shitty code is probably in its training data :P
I was looking at this wondering where are the previews, images, etc... yep, right, this is for people who can't see properly.
Was pretty eye opening.