"Increase information density—with ASCII art!" is problematic for accessibility

[dbjorge]

There is an item in the Output section that reads:

**Increase information density—with ASCII art!** For example, `ls` shows permissions in a scannable way. When you first see it, you can ignore most of the information. Then, as you learn how it works, you pick out more patterns over time.

Unfortunately, while ASCII art can be great for improving information density for some users, it is generally problematic for accessibility and inclusivity:

• Screen reader users will generally have an experience ranging from "much more unpleasant than a visual user" (eg, with an ASCII art table) to "completely unusable" (eg, for most ASCII art progress indicators or product logos). Sections 5.3.2 and 5.4 of this research paper are good overviews of these issues.
• It tends to create/exacerbate formatting issues with text wrapping at low line lengths, which disproportionately impacts users that need to use high zoom levels and/or font sizes
• Very high information density can also make it harder for folks with certain types of neurodivergence to parse the output

I think it would be preferable to rewrite the ASCII art item along these lines:

**Avoid using ASCII art!** This includes product logos in help and splash screens, progress indicators, and table-like formatting. ASCII art generally creates accessibility problems. For example, screen readers will announce ASCII art character by character instead of as a whole, and users that require high font sizes might see mangled output due to line wrapping.

**Table-like output requires extra caution.** Sometimes, a tool's output is naturally tabular, and it can make sense to support output formatted like a table. However, users of accessibility technologies (for example, screen readers) will not generally be able to navigate tabular CLI output column-wise or row-wise - they will be forced to read the output line-by-line. To make tabular output more inclusive:

* **Allow the user to control the order and visibility of columns.** For example, `git log` provides both a `--format` flag that enables exact control over what data is displayed and several shorthand flags for different levels of information density.
* **Do not use unicode formatting characters to separate columns visually.** Unnecessary characters like `╣` create noise for ATs.
* **Support exporting tabular output to a tabular data format.** Users of accessibility technologies will be better able to navigate your table row-wise or column-wise if they can export it to, for example, a `.csv` file or an `.html` file with an embedded table.
* **Any output visible in a table should also be present in other structured output formats.** For example, if you support a `--json` option, ensure that all the output exposed as a table is also exposed there.
* **Avoid using tables to format non-tabular data.** For example, do not copy the default no-argument behavior of `ls`.

---

I considered adding this as a comment on #5, but I thought this felt more immediately actionable when taken on its own, so I made it a separate issue.

[severak]

There is already section about disabling of color output. I think we can elaborate in similar style:

If the USING_SCREENREADER environment variable is set, output should be screenreader friendly.

For example, instead of using animated progress bar ([=====> ]) it would output something like:

10 % done
20 % done
30 % done

while it's doing own thing. Ideally - these screenreader alternatives to ASCII would be incorporated in libraries so they will be standardized to most usable variant.

I think sometimes ASCII art can be valuable and actually makes sense in some cases (for example tree command) .

However I have exactly zero experience with using screenreader so I can't tell if this was done before.

[l0b0]

It's weird that the ASCII art example is tabular output - a table is not ASCII art, it's literally just whitespace-aligned text, without any borders.

[eqn-group]

I think if you are blind, this program is not for you. if this program is an issue use different tool. This must be left to the program author if they want ascii art or whatever.

[ssokolow]

I think if you are blind, this program is not for you. if this program is an issue use different tool. This must be left to the program author if they want ascii art or whatever.

The point is that it shouldn't be encouraged in a list of general-purpose guidelines because it's not something that's virtuous in all situations.