My Thoughts on the Current State of Command Line Accessibility

I am a heavy user of the command line, and command
line oriented operating systems such as Linux and
OpenSolaris. I am blind,
and use a screen reader to access my computer. This means that
various things are inaccessible to me, such as captchas that have no
audio alternative. The command line,
being mostly text based, is almost perfect. I say
almost perfect, because the screen reading technology isn’t really geared
towards certain types of text. Consider that as new
text arrives, the screen reader will attempt to read it, from
top to bottom, left to right. This works perfectly
in programs such as ed, because I can type a command and get a response on the next line.
However, this all falls apart when certain classes of programs are invoked,
such as screen editors (vim, emacs), some parts of
mailers (pine, mutt), and tabular output
utilities (df, vmstat, prstat). These programs are in different classes and have
their own problems, so I’ll discuss them below.

Full screen applications

The problem with these is that a screen reader
doesn’t know that, for example, j will move
the cursor to the next line in Vim. Nor does it know that l
will move to the next character. if I type
j in vim, or ^n in emacs, the screen
reader will attempt to read what has changed on the
screen, which is usually nothing – just
the position of the cursor. At this point,
the screen reader isn’t sure if I typed a j because I wanted to insert a j, or
if I typed a j because I wanted to move to the next line. I can
attach, at least in the windows screen readers, a script to the j key, but that wouldn’t always be accurate due
to network delays and such – I have no way of knowing when the cursor
has successfully moved in order to read. This isn’t
a stop-all for screen programs, but personally, I would rather focus on
my work rather than hitting j, and then whatever
command my screen reader uses to read the current line. This gets
progressively more annoying when I attempt to move by character – character right, read
current character. There are scripts tied to the arrow keys, but those sometimes don’t work, and conflict with
the automatic echoing of newly written screen text. Ed is great,
but it’s not so good for writing emails that are
expected to be word wrapped, nor is the lack of an edit current
line function beyond ^u and ^w – if I realize that
I’ve made a typo at the beginning of the line, I have to either kill
the line and retype it, or hit enter, fix the typo and keep writing.

Tabular Output Programs

Tabular output programs produce output in a columnized table format,
for example:

Filesystem             size   used  avail capacity  Mounted on
fs/home/tyler          109G    86G   4.1G    96%    /export/home/tyler

This is a rather simple table, and mostly self explanatory. I’ve used
the df command so many times, and it doesn’t have too many columns, so I can find out where
I am relatively easily. But in contrast, take this vmstat output:

 kthr      memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr dd dd f0 --   in   sy   cs us sy id
 0 0 43 428760 14456  1   4  3  1  1  0 51  6  0 -0  0  426  106  109  1  3 97
 0 0 52 416600 21632  1  23 105 0  0  0  0  0  0  0  0  851  490  276  1  7 93
 0 0 52 416600 21632  7   7  0  0  0  0  0  0  1  0  0  801  489  263  1  6 93
 0 0 52 416600 21632  7   7  0  0  0  0  0 19  0  0  0  942  410  451  0 26 74
 0 0 52 416600 21632  7   7  0  0  0  0  0  0  0  0  0  813  475  246  1  6 93

This table has approximately 22 columns, with different sized numbers. I can bring my
screen reader’s cursor to, say, the SR column, and go read down by words, but if a 100 suddenly
changes to a 0, the number will move and the screen reader will get confused on which way to go –
left or right – to find it again. I can find myself
reading some other column that I don’t intend to read, but might not notice. Of course,
reading this from top to bottom, left to right is impossible.

I propose a solution to all this. A screen reader, in userspace, that will
wrap the shell and provide commands for moving around. While such
things exist, for example
I feel that there should be an easily modifyable,
extendable screen reader, perhaps written,
as the Orca project for gnome,
in Python. Orca is all
well and good for the Gnome desktop, but it’s terminal support feels like it was
added on as an afterthought, at least to my view of
working. I want something that is
stable, reliable and customizable. In-kernel
screen readers are great if you want to view the boot messages, and are even nessisary for certain
types of recovery operations where a serial console is unavailable, but this adds the complexity of
kernel development and restricts the languages that they can be written in.


Tags: ,

One Response to “My Thoughts on the Current State of Command Line Accessibility”

  1. drj11 Says:

    It’s not every day I see someone say “Ed is great”!

    ed can pipe bits of the file through a command like fmt to do paragraph formatting, but you have to use an external file and it’s a bit tedious. Example:

    1,2w !fmt > o
    2r o

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: