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!

After the "links" link, there are three links that are not labeled (have nothing between the <a> and </a> tags. Other than that, it looks good.

@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 ( has an --accessible option that removes colors, ASCII art, etc. and I like the idea. I'm working on 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?

@mecinus Redraw the screen as little as possible. You can Redraw lines, but not like whole screens.

@mecinus @devinprater
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.

@devinprater Hi, I maintain I already used it myself with Talkback and let some accessibility tools check it so I am hoping the accessibility is in a pretty good state but a more human touch may catch issues I've missed would be awesome :)

@SylvieLorxu Yes, this looks really good. Thanks for caring about accessibility!

@devinprater Not really accessibility test, but I do have a question and maybe you'll be able to provide a better answer than what I find online.

There's a thing called EXIF data with which you can add meta data to e.g. images. This also includes things like "description", "caption", etc.

On fedi we have image descriptions, but that's completely different from the EXIF data in the image.

For Pleroma I currently have an MR open to read the EXIF data and prefill the image description with that. The idea is to later go the other way around as well. That way image descriptions can be more portable (i.e. You post an image, give it a proper description, someone downloads it, now other software can still access the image description through the correct EXIF data fields. If someone wants to upload the image again, the image description field will already pre filled and they can choose to keep the description or not.).

The problem I have is that I'm unsure what EXIF data fields I should use. I now use -ImageDescription, if that's empty, it will check -iptc:Caption-Abstract.

So my question is if you happen to know a bit about these things, and if so, what's best to use here.

If this isn't something you know either, do you happen to have some good examples of images that have descriptions like that? Then maybe I can check what fields are used. (Or you can run `exiftool path/to/image` and see what fields are used.)

Long post 

@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.

Long post We discovered that Discord has alt text portability under some specific circumstances but we never quite figured out exactly what they were beyond that copying a specific image with alt-text into discord would automatically fill the field

Long post 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

Long post 

@evelyn @ilja @devinprater

I would wager a guess that this has something to do with "rich text in clipboard" kind of functionality... I'm sure you noticed before that if you copy text from a website or PDF into something like MS Word, it carries over formatting data...

Some Google results:

I guess web browsers might be putting whole HTML into the clipboard, so you can copy-paste rich content between websites. Probably, the receiving website has to support it...

I googled how to read HTML from the clipboard:

So what's probably happening is that your browser puts a whole <img> tag with alt text into the clipboard when you copy an image with alt text from pleroma, and discord makes use of that.

re: Long post 

@devinprater @ilja IIRC my dad did something like this for the descriptions in his custom photo gallery (now offline), might been loosely related to our shared blind family member so they could still browse through it.
It's a thing I should do here for my own photos, specially as it would also make it easier to search in them.

@ilja @devinprater If you don't find a cannonical answer, putting it in any field is better than not :)

Maybe a prompt that defaults to yes on overwriting existing data when it exists.

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.

@devinprater thanks for the feedback. I will take a look later today and publish an update.

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 (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 

@mathr @devinprater I wrote about accessible CLIs:

Respecting NO_COLOR, keeping output consistent and predictable, conforming to conventions, and offering manpages that can be converted to HTML will get you most of the way there.

re: CLI best practices 

@Seirdy @devinprater

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 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.) 💕

@devinprater I would be grateful if you could appraise my website for accessibility.

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.

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 🤷🏼‍♀️

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.

Sign in to participate in the conversation
Light space

A home where one can be themselves.