Please boost for reach. So, anyone that is working on FOSS projects like web apps, sites, Linux apps, desktop environments, or other user interfaces, please let me know if you want them tested for accessibility. I can do both CLI, web, and GUI testing, and app testing on Android. I'm running Debian (on a ChromeBook but that's not too important), so just give me the name of the package, or the URL of the site or app. I can also do Flatpak!
@devinprater Interesting you mention CLI. I always had the impression (based on ignorance) that CLI applications were always accessible, at least for people with vision issues. What could go wrong with a CLI application? What are the points to check?
@bortzmeyer Like Flatpak, refreshing the whole screen. The CLI Reddit clients do this too. TUI programs, mainly. Oh and using Unicode for progress bars and such.
@devinprater Ah, OK. I was thinking of "pure" CLI programs, writing only visible characters to the screen. Indeed, if they play with terminal escape sequences or do ASCII art (not even Unicode art), they can certainly confuse the screen reader.
I noticed recently that if you run “firejail … reportbug…” firejail blocks all dbus connections, including /org/gnome/desktop/a11y/. I don’t know much about accessibility, but a11y apparently refers to #accessibility services. So Debian’s reportbug CLI tool is proactively trying to talk to a11y. Other CLI apps I run in firejail don’t get a warning that a11y is blocked, so I suppose that means CLI apps are not generally making themselves accessible.
BTW, I wish “accessbility” weren’t named as such because it causes confusion when normally it’s used when discussing whether something is accessible to non-impaired users.
@devinprater Very interesting, especially CLI testing! I realized that rustscan (https://github.com/RustScan/RustScan) has an --accessible option that removes colors, ASCII art, etc. and I like the idea. I'm working on ncgopher (https://github.com/jansc/ncgopher), but I guess that the rust TUI framework I use (cursive) does not provide any accessiblity features, lots of screen redrawing in ncurses. Any suggestions on how to improve things?
I have a very lightweight tool written in Rust named highlighter and the idea is to add ASCII colors based on regex, but it has a flag --clean that removes any ASCII colors. This is the newest feature and is living on a local dev branch until I test it thoroughly. The git repo is available here:
I hope you find it useful.
@ilja I've never heard of that before, sorry. But I don't think this has been really thought about either. You may be the first to consider image description portability. No image I've ever come across have ever had a description built into the file, that I know of.
@email@example.com @firstname.lastname@example.org I did look into which exif field was best suited to this a bit back and I wasn't able to work it out then, but there's a few, and I suppose the best approach would be to attempt each exif field in turn from the less standard but highest specificity (description, caption, etc) to the least (title, etc) to set the alt text field in the software, and then to store the decided description in all of the possible tags
re: Long post
That is a nice idea. Perhaps I have in 1 or 2 years a workable Version ( I worked 15 years on it now ).
@devinprater hey, loved this initiative. Any chance you could test adriconf for accessibility?
Or if you can tell me which tools to use I'm happy to do it myself.
@jlhertel I downloaded it from Flatpak, is that what I was supposed to do? I couldn't find an icon for it. Oh wait isn't there a way to run stuff from Flatpak on the command line?
@jlhertel Okay, so some of the buttons read, like "default" and "add". The three tabs have no labels, and neither do the toggles. I'm using the Orca screen readers to test it, with standard navigation keyboard commands: Tab, Shift+Tab, Arrow keys, ETC.
CLI best practices
Thanks for offering to do this!
It made me think I could probably improve accessibility of my programs.
Do you have any resources for best practices for accessible CLI apps?
So far I have added command line options to my (non-interactive / batch) program for downloading from archive.org (it just prints to stdout and stderr, no ncurses or anything):
1. disabling ANSI colour codes (normally I use green for ok and red for failed)
2. disabling download progress bars (which go to stderr when enabled; all other output goes to stdout)
3. reducing verbosity (only print messages for errors instead of a flood of "all ok")
and I now redirect some things to log files (like timestamped URLs) that are not so interesting to read except if something has gone wrong.
I also return proper exit codes to the shell so callers can tell if anything went wrong.
Is anything else obviously missing?
CLI best practices
@mathr Just don't use Unicode of ASCII graphics, and you're good for simple CLI tools.
re: CLI best practices
re: CLI best practices
I added NO_COLOR support as it was very easy.
A proper manpage is a good idea, I hadn't thought of that, most of my software only has separate less-discoverable documentation and (sometimes) --help output, which is much briefer. A lot of the time I end up reading the source code of my undocumented unreleased toys to remember what they expect..
Running man-db (as regular user with prefix under $HOME) after installing the manpage to $prefix/share/man/man1 makes man able to find it (I think it must inspect the PATH environment variable?)
I found out how to generate manpages from markdown using pandoc, which saves learning yet another syntax. I convert the manpage.md to HTML for the web based documentation, and the main README or web page can just link to it instead of duplicating work. The --help text suggests using man for fuller documentation, too.
@devinprater Oh, I recently migrated a website from wordpress to hugo, and had to rewrite much of the html and css. I did it with accessibility in mind but I'm no expert. If you're interested in taking a look at it, drop me a DM.
@devinprater And I truly hope that projects that have budgets use it to pay for that valuable work.
(And thank you.) 💕
I will have a Linux application for you to check as well when I reach the release stage. In fact, the thought occurs that perhaps this application might even be of use to those who need special accessible equipment. You can see the project called 'Locus' on my codeberg page. https://codeberg.org/Hamish_The_PolarBear/Locus
Thank you in advance for your help.
@devinprater I make FOSS Android apps but I have little clue how to make them accessible.
I recently learned that font size changing is important but other than that 🤷🏼♀️
@alchemicacht Maybe this could help, if you use just like Kotlin and Android's own GUI frameworks: https://developer.android.com/guide/topics/ui/accessibility
After seeing your toot today, we had a very brief discussion on our dev matrix channel and the response was very positive. We would be thankful if you can vet our CLI and GUI in terms of #accessibility and let us know which parts should be improved.
Our software, Flameshot, is an OpenSource screenshot and annotation tool and is available on Linux, macOS and Windows. Our CLI currently is implemented for Linux and macOS.
Thank you in advance.
A home where one can be themselves.