[accessibility] Accessibility of CLI

[Jonathan Fine]

Hi

I'm most grateful to Jason for his comments on this paper. It's clear that
Jason is speaking from a range of personal experience that I don't have.
I'd like to add some further comments, based on my own range of experience.
Also, as both a pure mathematician and a software developer I have some
experience and fondness for building abstract theories. So you may need a
pinch of salt.

First, to state the obvious, this is a peer-to-peer paper for the community
of experts in accessibility of software tools. I'm outside this community,
but think this paper contains insights and knowledge of practice and
influences that many outside that community would benefit from knowing.

Also obvious, the paper uses what might be called social-science or
usability methods, such as interviews, test activities, measurements and
hypothesis testing. A couple of hours reading Steve Krug's
https://en.wikipedia.org/wiki/Don't_Make_Me_Think would bring most readers
up to speed sufficient to appreciate what's been done in the paper.

I'll now jump to the paper's recommendations. They are:

1. Ensure that a HTML version of all documentation is available.
2. Provide a way to translate long outputs into another accessible format.
3. Document the output structure for each command.
4. Provide a way to translate tables in CLI output into another accessible
format.
5. Ensure that all commands provide status and progress indication.
6. Ensure that all status and progress indicators used are screen reader
friendly.
7. Ensure that error messages are understandable when read aloud.

You might not agree with these recommendations. I've been in many software
developer discussions where people argue for (or against) a change based on
what is sometimes little more than personal opinion and preference. This
paper's authors are part of a community where there's peer review of
publications and requirements to provide evidence. This helps opposing
points of view get the consideration and respect that they deserve.

Now for a new idea. Being a sighted developer I benefit from the colorized
output produced by many standard Unix commands, such as 'ls'. This is
possible because:

A. The terminal supports https://en.wikipedia.org/wiki/ANSI_escape_code
which allows color, font styling and other display features to be
controlled.
B. Commands such as 'ls' emit ANSI escape sequences (when writing to an
ANSI-enabled command line console).

Now for another new idea. Recommendation 1 is that "a HTML version of all
documentation is available". That documentation, when called for, has to be
displayed somewhere. But for a blind user 'displayed' has a different
meaning.

Putting these together, the idea emerges that one wants an 'HTML console'
whose outputs can include HTML documentation. Such already exists, for
example https://en.wikipedia.org/wiki/Project_Jupyter#Jupyter_Notebook.

One more idea. Python documentation uses
https://docs.python.org/3/library/doctest.html to verify that CLI
interactions in the documentation work exactly as shown. An enhancement of
this would provide a way to add accessibility hints to the output so that
the resulting HTML would be more accessible to the visually impaired.

All these are examples of the insights and influences that contained in
this paper that developers who wish to enhance accessibility can benefit
from.

Finally, a word about LaTeX. This paper seems to be authored in LaTeX and
it contains what appears to be screenshots of CLI interactions as bitmaps.
Just as latex can 'pygment' language source code, so sure it can allow CLI
interactions to appear in PDF as text rather than bitmap image.

I think that's enough for now. There's an opportunity to discuss this at
this week's TeX Hour.
Thursday 10 February, 6:30 to 7:30pm UK time.  The UK time now: https://time
.is/UK.
The URL is:
https://us02web.zoom.us/j/78551255396?pwd=cHdJN0pTTXRlRCtSd1lCTHpuWmNIUT09

wishing you more accessible TeXing

Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/accessibility/attachments/20220207/a0e732d2/attachment.html>