An Introduction to Speech-Access Realities
for Interested Sighted Internauts

The following is a brief explanation of how information is presented to the speech-user as he or she crawls the web. Although originally composed in 1996, and despite epic efforts to ensure that the underlying specifications that comprise the web no longer present barriers to access, but, in fact, provide programmatic means of breaking down such barriers, and the promulgation of guidelines on correctly implementing such peer-reviewed and internationally recognized standards, the experience of the average blind user (if any user can be said to be "average") hasn't changed much from what is described below. Comments, criticism, suggestions, and hate mail should be addressed to Gregory J. Rosmaita, <oedipus@hicom.net>

Most screen-readers work on the physical/visual level--the PC cursor physically moves you about the screen and through documents, while the voice/speech cursor allows you to "glance" around the page without interacting with the currently open application. Yet, while it is tempting to say that the speech/voice cursor acts as one's eyeballs, the analogy is not quite apt, as the speech user is still "looking" blindly about the screen. Nor is the blind user able to construct a "gestalt view" of a page -- that is, the simultaneous processing of all of the information contained on a page or in a given interface into an integrated whole, as opposed to building a working understanding of a page or interface by serially encountering each element of that interface or page. Even if a blind or visually impaired user has listened to the ENTIRE screen beforehand, one cannot always pick up on the visual cues -- such as table-ized layout; changes in font family, font weight, or font color; ASCII art, and other uni-modal markers of importance and function utilized by the page's author -- when they are not programmatically made available to the user's screen-reader. The reality of the web is that they are very rarely provided -- due mostly to ignorance and the over-reliance of web-content developers on visual tools to construct pages that, consequently, only make sense when processed visually and which do not "transform gracefully" into non-visual modalities. Moreover, when one is using a pointing device to drag-and-drop elements of a page's interface to achieve a specific visual result, it is hardly likely that such an interface can fully be accessed without a pointing device.

So, just how does a speech user browse the web? While there are as many answers to that question as there are speech users, there is an easy answer to the question:

SLOWLY

A speech or braille user cannot "scan" a page to quickly locate pertinent information -- he or she has to listen to or tactilely read (on a 20 to 40 cell refreshable display) the entire page to locate whatever it is he or she loaded the page to find or hope that whatever they are looking for is programmatically apparent to his or her assisstive technology.

Don't get me wrong -- I don't mind using my screen-reader, which, after all, is my virtual eyeball to "look" for visual markers -- I just need to know what I'm "looking" for, as my virtual eyeball is connected to a PC, and, hence, unlike an actual eyeball, isn't automatically drawn to visual markers. (Which, incidentally, is the Achilles' heel when it comes to access to the now near ubiquitous GUI, a visual interface to which most applications -- not to mention most web sites -- are tailored. A screen reader is like a blind person inasmuch as it has no way of ascertaining what a graphical element or icon represents, unless that graphic has been labeled -- a limitation which seriously compromises blind individuals' access to graphical applications.)

The most effective way to read a page aurally is to "kill" speech while the page loads and then review the page using the screen reader's voice/speech cursor and the "read-entire-screen" keystroke command. And yet, I have worked with power screen-reader users who have been online far longer than I, to whom this method of webcrawling (still the most apt metaphor for traversing cyberspace without the old orbs) has never occurred. Nor is everyone aware that a text-based browser, such as Lynx can be set to display numbered links, which makes activating each link directly easy through the use of simple keystrokes (just type in the number of the link you want to follow, and Lynx will fetch the page). Nor is everyone aware that even on a system which disallows saving options changes made within a Lynx session (and there are a hell of a lot of those out there, too), that one can import a customized .lynxrc file into one's account.

Filtering punctuation is extremely subjective, and often the speech-output user (if his or her screen-reader allows) uses different settings for different programs. When using word processing software, for example, I have the screen-reader which I used to compose this document, set to pause appropriately when it encounters a punctuation mark, rather than having it vocalize every coma, period, and semi-colon. When encoding HTML, however, or working at a DOS or a Unix/Linux prompt, I have the puntutation filter set to "say all", which means that every single character that a 101-key keyboard is capable of generating will be spoken.

When I am crawling the web -- and a more apt metaphor for traversing the web without vision has yet to be devised -- I have my punctuation filter set to "say none", mainly because until the autumn of 1995, I used a very old screen-reader that wouldn't let me filter out punctuation when I was in terminal emulation mode, and, consequently, I had to endure the audiblization of every damn comma, period, semi-colon, bracket, parenthesis, etc. that appeared on-screen. Needless to say, it contributed greatly to the general lack of coherence so evident in this essay.

It is a depressing reality, however, of blind computer use, that there are a lot of blind users out there using 286-model PCs (or less) and screen-readers of an early-to-late eighties vintage, which are far more primative and limited than the screen reader which i am using to compose this document.

Why the prevalence of obsolete screen access equipment?

1. Adaptive equipment is, by its very nature, extremely, and often prohibatively, expensive. It is not uncommon for a blind individual to spend twice as much on the adaptive equipment that enables him or her to use a computer than he or she did on the computer itself. And while the price of computer hardware decreases over time, the price of adaptive equipment--especially software--has steadily increased.
   
   
2. The state-of-the-art in DOS-based screen-access wasn't achieved until 1993/1994, just in time for obsolescence. But, what with the 70% unemployment rate amongst the blind, not everyone has/had the 495-595 clams it costs to purchase a state of the art DOS-based screen reader.

...just a few of the reasons why such things as Blynx, Blynx386, Blynx32, and the Web Accessibility Initiative exist.

Thanks to Al Gilman for the suggestion that I incorporate this rant (originally posted to the Lynx-Dev emailing list in 1996) into a hypertext document and for suggesting the title.