Email or username:

Password:

Forgot your password?
Devin Prater

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!

#a11y #foss #linux #flatpak #accessibility

8 comments
Stéphane Bortzmeyer

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

Devin Prater

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

Stéphane Bortzmeyer

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

Jan 🇧🇻

@devinprater Very interesting, especially CLI testing! I realized that rustscan (github.com/RustScan/RustScan) has an --accessible option that removes colors, ASCII art, etc. and I like the idea. I'm working on ncgopher (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?

Sylvia van Os

@devinprater Hi, I maintain github.com/CatimaLoyalty/Andro. 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 :)

ilja
@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.)
@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.
Go Up