Okay so I might as well tell y'all what I'm thinking. I'm planning on making an accessibility room/channel/server/kitten where we can all gather and coordinate on accessibility issues in FOSS, encourage each other, and generally be a bunch of users and developers working together.
@devinprater, oh, count me in. I've been on the bench lately, but I've had a similar idea. I wanted gather people and fix things, I even bought a domain name.
But, I'm not "only" trying to make FOSS more accessible, I've got bigger ambitions and I eant to rebuild "everything" scratch. If thing catch on, I'm hoping that the Overton Window will help nudge people in the right direction.
@devinprater, I've started looking at markup languages, programing languages, data serialization and communication protocols, everythimg needs to be improved. Most importantly GPUs and screens need to be on par with some accessibility cards.
It's hard to fix the current complex ecosystem, but things can be accessible from the get-go and all this cloud virtualization gave us a chance to fix things. I'm hoping that the QubesOS approach could be taken as an example.
@devinprater, what I'm trying to say is that, for the last decade or so, we had decent enough hardware to add some temporary abstraction layers, we just needed the software to catch up, and it kind of did, now we need to start the cleanup, but we need to do it from the ground up.
Starting with writing text in a decent markup language supported by various tools, including Matrix which is in your list. Then we need a decent programming language, and I'm not sure we have such a thing.
@devinprater, once we have that, the CLI tools will need to be revamped, we need a new type of terminal, one that outputs semantic markup or something even more basic, some binary serialized data without any text encoding and number formatting.
I know, it sounds scary, but I don't want my disk management CLI tools have to know about my the number formatting quirks in my language, that text only adds complexity, bugs (like in qubes-core-admin) and potential security issues.
@devinprater, and let's not talk about English... it's the worst human language to write a programming language or have a text-to-speech engine on top of it.
I've started down this "improve accessibility" path a long time ago, at first I started reading about constructed languages and learned Esperanto and I've read lots of papers about communication in general, learned about the "World Atlas of Language Structures" project and I now kind of want to use the Interlingua language for everything.
@devinprater, I've started on this "improve accessibility" research a long time ago. I've read countless papers, watched videos, listened to podcasts and I've even read a few standards, but everything is still in my head. I've got a general direction in my head, but I never took the time to write things down. I'm blaming this on "perfectionism" or whatever word neurotypicals use for "good enough". I really need to put some words into a markdown file in git and have a static site on gemini & web.
@walter I kinda think we should start with improving what's already here, but your long-term ideas are quite ambitious. But not many people, especially disabled people, are going to want to learn another language just to interact with their computer.
@devinprater, I'm well aware of how it sounds, but I can still dream. One more thing and I'll stop with this craziness. With the exception of not using English for everything, all other ideas are not really radical and people area already going in that general direction, but for other reasons like: resource consumption, privacy, security or productivity (via separation of concerns and having developers specialized on the frontend or backend).
@devinprater, a lot more people will help improve accessibility if the problems are "properly" framed. For example:
I really want my phone battery to last a week. This isn't going to happen if resources are wasted on animations for a screen that I can't use in the sun. For this we can have apps with swap-able UI: one containing all the Gnome fancy animations, another one that works well on e-ink screens and a 3rd one for screen readers. And, in the end, we can move screen readers into hardware.
@devinprater, with the above changes we also get the solarpunk people on board.
To get the security folks on board, we just need to drop everything related to UI from the programs. CLIs don't need to know about UTF-8, or how to format string and numbers in the proper language, the programs could use an ID for the message and a binary serialization protocol. The raw bytes could could then be used directly or wrapped in some semantic markup. And bye-bye bugs like:
@devinprater, I could go on, but it's almost morning here. Let's keep in touch, I'm sure that we can find a lot of people to help.
P.S. Talking about what's already here, it might sound counterintuitive, but Orca could use some UX improvements dedicated for developer that don't need screen readers.
I liked the UX in the now-obsolete "Fangs" screen reader emulator add-on for FireFox, check their FAQ for: "Why haven’t you integrated Fangs with a voice synthesizer?"
A home where one can be themselves.