Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make ouch accessible #194

Closed
AntonHermann opened this issue Nov 12, 2021 · 1 comment · Fixed by #197
Closed

Make ouch accessible #194

AntonHermann opened this issue Nov 12, 2021 · 1 comment · Fixed by #197

Comments

@AntonHermann
Copy link
Contributor

AntonHermann commented Nov 12, 2021

The warnings and info messages are not accessible at the moment, the square brackets are most likely read out as square brackets and I'm not sure whether having a message for each (de)compressed file is valuable for a sight-impaired person.

Motivation
See this blogpost for some arguments/guidelines for making hacking accessible (there are many CLI specific informations)

What should change?
Not much actually, I think adding an accessibility option and disabling all info! output as well as removing the square brackets for warning! output and checking all (e)print(ln)!s whether they provide value to a sight-impaired person.

Implementation ideas
I don't know whether it would be too much clutter to pass this option to every output macro call, so here are some ideas how this could be implemented in a less noise way:

  • Pass it to every output macro, but extract this and other flags into a new struct that can be passed around comfortably (the subset of opts::Opts that can be Copyed)
  • Use an env var instead which can be checked in the output macros
  • global state (using once_cell)

This could be advertised as a feature in the readme. Many CLI tools are not designed with accessibility in mind. We could make a difference towards making CLI more accessible in general and thus including an often forgotten minority! 🎉

@AntonHermann AntonHermann added the documentation Improvements or additions to documentation label Nov 12, 2021
@AntonHermann
Copy link
Contributor Author

whops didn't know it would at the documentation label, that shouldn't be there

@marcospb19 marcospb19 removed the documentation Improvements or additions to documentation label Nov 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants