address accessibility story

[zkat]

How accessible are these errors? What changes could be made to make them easier to consume for visually impaired folks? We should have a reasonable story for this before 1.0 goes out. Right now, I don't imagine it's very useful to get these error messages.

[Mythra]

Hi!

Figured I'd leave my thoughts on the matter, as I also have some very similar errors for a tool I've been working on, and am a screenreader/braille display user myself. FWIW a fully 'colored' error of my tool looks incredibly similar to miette as it was inspired by orogene:

So hopefully this isn't too far off from miette. Most terminals don't really have a good story here, so the best bet is generally to offer options:

1. For color there is a standard CLICOLOR= variable that can be set to 1, or 0. It can be really wanting to setup some sort of 'color-blind' friendly colors, but this is pretty diminishing return as there are still lots of terminals like it or not that only have 16 color choices. I've found creating color-blind friendly variants in being unstandard, and small returns to not really be worth it (how many people are going to know a tool was built with miette, and to use: MIETTE_A11Y_MODE="red_green_unclear" to know to distinguish reds/greens a bit more, and is using a terminal where it'll actually do something because you have a wide range of colors?).

2. The best thing besides a color variant for screenreader users, I've found is to offer separate output modes that can be configured similar to how a user would expect with log formatting. I recommend having:

• A 'fancy' output format with/without colors where you show the nice multiline that is easier for people to read.
• A 'condensed' output format where more things are based on lines of information (this makes it simple for people like me who will be using a braille reader on a terminal -- e.g. OSX voiceover on terminal is pretty atrocious so it's just easier to use my braille reader there).
• A machine parseable (json is probably easiest because jq is a very easy tool to get) format that is well split up so a custom set of information can be extracted easily. Knowing I can just pipe all output to a file, and then use jq to get just what I care about later is honestly the easiest way to make sure I'm never blocked.

[zkat]

Thanks for your comment! This is super useful. The route I've ended up taking so far is to use NO_COLOR and some heuristics to figure out whether to do any fancy stuff, so it's very clear and easy how to opt out of it, and it applied globally! It does mean that it's a bit all-or-nothing, but I got some feedback that relying on more bespoke or obscure env vars might make it harder to discover? In any case, I definitely want the "narrated" output to be readable (and hearable), so I think turning NO_COLOR into a big hammer by default is ok?

re: CLICOLOR: I didn't know about that one! I'll be sure to add support for that alongside NO_COLOR.

Finally, 🤔 about it a machine-parseable version sounds really cool. I've created a separate tracking issue for that bit, because this issue is more about "human" output: #29