Re: Accessible terminal output

[Sam Hartman <hartmans@debian.org>]

Neils, I think what you are about to find is that individual preference
generally dominates accessibility concerns here.


>>>>> "Christian" == Christian Schoepplein <chris@schoeppi.net> writes:

    Christian> Hi Nils,
    Christian> On Sun, Jan 28, 2024 at 11:54:24AM +0100, Niels Thykier wrote:
    >> In my case, my tool is not interactive. It generates text output
    >> and either emits all of it on standard out or pipes it to a
    >> pager. It is closer to a tool like ls than mutt in spirit. As far
    >> as I know, my tool cannot control the caret of the output in any
    >> meaningful way in this case.

    Christian> Piping output into a pager is very uncomfortable for
    Christian> screen reader users IMHO. To navigate such content you
    Christian> either have to use the keys of a connected braille device
    Christian> or use the screen reader commands to go through the
    Christian> output. Both variants are much less good then piping the
    Christian> content into a programm where the user can navigate the
    Christian> output just with the normal arrow keys, like navigating
    Christian> through a file in an editor, or piping the content into a
    Christian> textbased browser like w3m where the content also can be
    Christian> navigated by using the arrow keys.

I'd much rather have content in less than in w3m.

1) I do have my screen reader controls optimized for something I like to
use, so being able to navigate with the screen reader keys is in my mind
a plus not a minus.

2) I always have less available; I would not normally expect a text mode
browser to be available on a remote server.

3) I find pagers to be a good interface in the common case I actually
want to read the entire screen. I find the simple ":" prompt of less or
the "--more--" of more less disruptive than a status line of an editor
or browser.

For me, reading tabular output, the best advice I can give is to focus
on making the  table row elements as simple as possible.
For example separating each row element with a single pipe and spaces
rather than something more complicated.
I appreciate that the header line--or the separator between the header
and the rest of the table--may be more complicated.
That's not a big deal, but the more lines with lots of dashes I have to
work through, the more annoying.

I would definitely find pipe separated text easier to read than CSV.
Although in exceptionally complicated tables, I would find being able to
take CSV into a spreadsheet convenient.


For reasonably simple tables,  I would probably choose to read pipe
separated text rather than to take HTML5 and read it in Firefox.

I find the text output of  sqlite entirely reasonable unless the number
of columns in the table gets large enough and the data is sparse enough
that I cannot remember what column is involved.
I generally refine my query in that case rather than  turning the table
into html.

--Sam