<div dir="ltr">Hi<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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 <a href="https://en.wikipedia.org/wiki/Don't_Make_Me_Think">https://en.wikipedia.org/wiki/Don't_Make_Me_Think</a> would bring most readers up to speed sufficient to appreciate what's been done in the paper.</div><div><br></div><div>I'll now jump to the paper's recommendations. They are:</div><div><br></div><div>1. Ensure that a HTML version of all documentation is available.</div><div>2. Provide a way to translate long outputs into another accessible format.</div><div>3. Document the output structure for each command.</div><div>4. Provide a way to translate tables in CLI output into another accessible format.</div><div>5. Ensure that all commands provide status and progress indication.</div><div>6. Ensure that all status and progress indicators used are screen reader friendly.</div><div>7. Ensure that error messages are understandable when read aloud.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>A. The terminal supports <a href="https://en.wikipedia.org/wiki/ANSI_escape_code">https://en.wikipedia.org/wiki/ANSI_escape_code</a> which allows color, font styling and other display features to be controlled.</div><div>B. Commands such as 'ls' emit ANSI escape sequences (when writing to an ANSI-enabled command line console).</div><div><br></div><div>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.</div><div><br></div><div>Putting these together, the idea emerges that one wants an 'HTML console' whose outputs can include HTML documentation. Such already exists, for example <a href="https://en.wikipedia.org/wiki/Project_Jupyter#Jupyter_Notebook">https://en.wikipedia.org/wiki/Project_Jupyter#Jupyter_Notebook</a>.</div><div><br></div><div>One more idea. Python documentation uses <a href="https://docs.python.org/3/library/doctest.html">https://docs.python.org/3/library/doctest.html</a> 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.</div><div><br></div><div>All these are examples of the insights and influences that contained in this paper that developers who wish to enhance accessibility can benefit from.</div><div><br></div><div>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.</div><div><br></div><div>I think that's enough for now. There's an opportunity to discuss this at this week's TeX Hour.</div><div>Thursday 10 February, 6:30 to 7:30pm UK time.  The U<span class="gmail-il">K</span> <span class="gmail-il">time</span> <span class="gmail-il">now</span>: <a href="https://time.is/UK" target="_blank">https://<span class="gmail-il">time</span>.is/<span class="gmail-il">UK</span></a>.</div><div>The URL is: <a href="https://us02web.zoom.us/j/78551255396?pwd=cHdJN0pTTXRlRCtSd1lCTHpuWmNIUT09" target="_blank">https://us02web.zoom.us/j/78551255396?pwd=cHdJN0pTTXRlRCtSd1lCTHpuWmNIUT09</a><br></div><div><br></div><div>wishing you more accessible TeXing</div><div><br></div><div>Jonathan</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>