When reading, writing, designing, or programming, the totally blind individual is inevitably restricted to a one dimensional world, be it speech or braille. This linear stream may take the form of a single-line display on a braille output device, or the words spoken by a speech synthesizer. There are brief moments when the blind user can enjoy the benefits of a 2 dimensional presentation. If he has a braille printer he might print out a chart or spread sheet and explore it with both hands. Indeed, when I studied mathematics at U.C. Berkeley I often had to write the equation, or set of related equations down in braille, and review it as a whole, before I understood it. However, one rarely has the time to construct such a 2 dimensional tactile representation, similar to the screen or the printed page. As a general rule we must admit that the blind user is stuck in one dimension.
Unfortunately, almost all modern applications present information in a 2 dimensional format, and most employ graphical icons that have no meaning for the blind. Since it is impractical to rewrite all these applications, the blind community has been forced to perform a rather awkward retrofit, using various adapters. We should recognize that this is not the ideal solution. Pasting a screen reader on top of Netscape makes it accessible, but the result is hardly efficient.
Over the past decade a small minority of blind users have discovered Linux, a free, text-based operating system for the home computer. Linux applications rarely employ graphics, and most of them are already linear, just like the mode (speech or braille) that is our Karma. All other things being equal, Linux is the best operating system for a blind user.
Of course things aren't always equal. If your job requires the use of a proprietary order entry system that only runs on Windows, then you'll be using Windows, with an adapter that tries to make the application somewhat accessible. But this scenario is actually quite rare. An employer may insist on a Microsoft Word document, but that doesn't force you to use Windows. You can write html code on Linux and mail it to your boss, who can then import it into Word. Conversely, your co-workers can easily export their Word documents into html for your benefit. Or you can use the catdoc program. There are very few reasons why you must use Windows. Let's assume you are considering Linux, where the applications are less graphical. That's a fair assumption, since you're already visiting this web site.
If you watch a sighted Linux user for an hour, you will notice that he spends most of his time in screen applications. He doesn't need the labyrinth of "helpful" menus and drop down boxes that Windows is famous for, and he has no patience for the "are you sure you want to do that" and "click ok if you really want to quit" dialog boxes, and he'd rather type in a cryptic command than click on a cryptic icon, but at the same time, he's not willing to give up the power that comes from a 2 dimensional visual search and scan. Thus the Linux editors, browsers, and mail clients still present information screen by screen, and the sighted user assimilates information by the page, his eyes jumping straight to the item of interest. This kind of power will never be available to us. To think otherwise is to live in a state of denial. I call it "screen envy", and unfortunately, most blind people suffer from this malady, whether they realize it or not. That's why they swear by their screen readers, scraping across 2 dimensional applications.
Even though the blinux community has taken two courageous steps away from graphical interfaces, it is still married to the screen. We try to squash our 2 dimensional applications into the linear streams of braille and speech, because it seems easier than rewriting those applications from scratch. And indeed it is, in the short run, but screen readers and screen applications will never be as powerful as a well-designed command line program that conveys a minimum of output, tailored precisely to our needs.
At this point I should admit that the above assertion is a matter of opinion - my opinion - and there are many intelligent people who disagree. Every existing adapter (except mine) reads the text on the screen, and only the text on the screen (or related attributes of that text). You may not want to call them screen readers, but that's what they are. These adapters are then used to "explore" the pages that result from various applications such as emacs and lynx. Dozens, even hundreds of blind users are happy with this arrangement. However, for reasons that are difficult to articulate, I am irreparably confused by screen programs, no matter how excellent the adapter, and although I may be part of a minority, I am definitely not alone. Consider a simple edit in Emacs. The blind user must track the reading cursor (the words he is hearing or feeling) and the visual cursor (where the "work" is being done) simultaneously. Often they are close together, but sometimes the user must read other parts of the document, e.g. when moving text about, and it is easy to get lost.
In my opinion, the "friendliness" of an application is measured by its output: the less the better. I don't mind typing detailed, often cryptic commands to get precisely what I want, as long as I don't have to wade through extraneous output. Let's take a simple example.
Unix has an ls command that lists files and their attributes. The output looks something like this.
-rw-r--r-- 1 eklhad eklhad 5429 Apr 10 18:43 cli.html
This is fine for the sighted user. He only has to type a few keystrokes, and his eyes jump right to the field he is interested in. In contrast, my ls command, which I wrote myself, accepts many more parameters and generates far less output. If I want to know the permissions, I use the -p option, and it prints 644. The -l option gives the length, the -t option gives the mod time, and so on. This is how I want to interact with my computer, every hour, every day.
I subscribe to the same philosophy when editing a document. When it comes to text editors, I've never found anything significantly better than /bin/ed, written some 30 years ago, and I probably never will. When I call up a file, the only output is the length of the file. If I want to read a line of text I have to ask for it. There is no need to plow through a screen's worth of data to find x and change it to y; I just type /x to find the line containing x, then s/x/y to turn x into y. Now that's power, and it's been around for a very long time.
Of course ed is a very awkward program in certain situations. Cut&paste operations, for example, are extremely difficult, because ed only operates on one file at a time. You must mark the block of text to be transferred, write it to a temp file, close the existing file, open the second file, and read in the temp file. In addition, the regular expressions are not as powerful as one would like. For this reason, I wrote my own line editor, which is (almost) ed compatible, but incorporates many new features. This program, which I call edbrowse, is a C program that runs on all flavors of Unix, and can be ported to other operating systems as well. If you take the time to learn this editor, you will be able to use it on any machine, for the rest of your life. Edbrowse uses the regular expressions that are native to perl (since it began as a perl script), and allows you to edit any number of files simultaneously, moving text between them as you like. It does all this through a command line interface much like ed. This takes some getting use to, especially if you've been raised on emacs, but I believe it is the most efficient interface for the blind user.
The browser is another important application in today's interconnected world, and unfortunately, every one of them is screen based. Lynx is the most blind-friendly, but we must remember that it was not written for the blind. The authors had a sighted audience in mind, and like Netscape and Explorer, lynx expects you to scroll through the document page by page, and move the "cursor" through the input fields of a data entry form. This does not mesh well with speech or braille. Filling out comment boxes and backtracking through web pages is particularly frustrating. For these reasons (and others), I added a browser to my line editor. That is why it is called edbrowse, a combination editor browser. You can edit www.ScrapSayings.com as easily as you would edit a local file. Edbrowse recognizes the domain name format and retrieves the web page from the internet. Of course you're not going to "edit" this page, but you can read through it using the command line interface. You can follow hyperlinks using the g (go) command, or place data in input fields using the same commands that are normally used to manipulate text. You can truly "edit" your comments before you send them on their way, a task that is virtually impossible in lynx.
Note, users of edbrowse can access an archive of mathematics at MathReference.com. Other sites that provide technical information, such as mathpages.com, are largely inaccessible. Some sites even place their equations in gif image files. :-( I wrote MathReference.com and edbrowse to work well together, making online mathematics available to the blind. At the same time, the pages still look "reasonable" to the sighted user, with subscripts and superscripts and Greek letters etc. But I digress; let's return to the adapted application.
Is it possible to write an application once,using a flexibile toolkit, so that it runs in either screen or line mode at the user's request? Suppose the widgits in your toolkit present information on the screen by default, but if you set $NOSCREEN in your environment, those same widgits operate in a command-response mode. Thus the aplication does not need to be rewritten from the ground up. This is an intriguing idea, but I remain somewhat pessimistic. I'm sure it won't work for editors and browsers. Edbrowse is radically different from emacs, and these two programs could never share a common design. The $64 question is, is that the norm, or is the editor browser an unusually complicated app, requiring considerable redesign to be efficient for the blind? I'm not sure.
In many applications, such as an editor or browser, the sighted user doesn't always "do" something to extract information. He doesn't call upon a widgit, so the widgit can't do anything differently in linear mode. Let's consider another example, the spreadsheet. There's a whole page of data, and the user doesn't click on anything to read it, he just moves his eyes. Yet a good spreadsheet for the blind would allow me to ask for the entry in row x column y, designating the row and column by number, or better stil, by some brief name such as fica or interest. So there's another real-world example of an important application that would probably have to be redesigned.
I'm afraid this holds true in any program where eye movements (which the screen program doesn't have to worry about) must somehow be converted into command responses, entirely new pathways for the linear version of the same program. Think of the application as a conversation between the program and the user. When the user ignores 95% of what the program "says" and selects the relevant 5% by moving his eyes, that conversation must change, in fundamental ways, to be blind-friendly. Most screen programs implement this type of mega-output conversation. That is in fact the screen paradigm. On this basis, I believe most screen programs must be redesigned, at a level below the UI layer, to become blind friendly.
Finally, command line applications are only as good as the adapter that supports them. Since every adapter, braille or audio, Windows or Linux, is a screen reader, I decided to write my own. I call it the Jupiter Speech System, the first adapter that is built with the command line user in mind. Jupiter is capable of reading screen memory, and some people do use it that way, but I spend at least 7 hours and 50 minutes out of each 8 hour day in line mode. This allows me to review the commands I have entered, and the computers responses, character by character if necessary, going back to the start of the login session. (Actually there is a limit to the text that is buffered in this way, but it certainly exceeds one screen. in fact the buffer houses the equivalent of dozens of screens, depending on the form of output.) If you prefer a command line interface, you might want this type of adapter.
There is a mailing list for users of Jupiter speech, edbrowse, and other command line utilities. You can join by sending mail to commandline-subscribe@yahoogroups.com.
In addition to the adapter and the linear applications described earlier, I developed a small patch to the Linux kernel that should make it easier for anyone to develop, test, maintain, and distribute adapters in the future. A kernel that has been patched in this way is said to be "blinux ready" - ready to accept a blinux-style adapter as a loadable module. This combines the ease and flexibility of a user program with the power of the kernel. It also simplifies the task of getting started if you are a newly blind user who is not terribly familiar with Linux. Let's face it - the last thing you want to do is recompile the kernel and master, with no mistakes, the nuances of lilo. If my patch became part of standard Linux, none of this would be necessary. You could download a dozen loadable modules off the net and install each one in turn, to see if you like it. Then deinstall it and install the next one, and so on. You might even prefer one adapter for certain tasks and another adapter for others. I already know people who switch between EmacsSpeak and Speakup, depending on the work they are doing at the time. Swapping adapters in and out on the fly would be much easier if they were loadable modules.
Note that this modular approach is not limited to the visually impaired community. For instance, I implemented an alternate keyboard for a one handed typist; I wrote it as a loadable module that plugs into my blinux-ready kernel. This module is only 100 lines long, yet it implements space chords that cannot be realized through loadkeys. Other adapters could map specialized input devices into keystrokes for the motor impaired, with word prediction algorithms, user defined macros, and so on. I hope that Linux makes this patch, or one very much like it, part of its standard kernel; computers would become more accessible to the entire disabled community, almost over night.
Send any comments or feedback to the author, Karl Dahlke, via email at eklhad@comcast.net, or telephone 248-524-1004 during regular business hours EST.
Click here for the author's home page.