The problem of providing feedback from the computer to a visually impaired user is examined. The use of traditional tactile input and output (Braille) is described. The limitations of voice output are discussed, and difficulties posed by complicated screen formats and screen review are considered

McMillin, Bruce M.

McMillin, P. Y.

English

Missouri University of Science and Technology (Missouri S&T): Scholars' Mine

Missouri University of Science and Technology Scholars' Mine Computer Science Faculty Research & Creative Works Computer Science 01 Jan 1989 Personal Computing for the Visually Impaired Bruce M. McMillin Missouri University of Science and Technology, ff@mst.edu P. Y. McMillin Follow this and additional works at: https://scholarsmine.mst.edu/comsci_facwork  Part of the Computer Sciences Commons Recommended Citation B. M. McMillin and P. Y. McMillin, "Personal Computing for the Visually Impaired," IEEE Potentials, Institute of Electrical and Electronics Engineers (IEEE), Jan 1989. The definitive version is available at https://doi.org/10.1109/45.31590 This Article - Journal is brought to you for free and open access by Scholars' Mine. It has been accepted for inclusion in Computer Science Faculty Research & Creative Works by an authorized administrator of Scholars' Mine. This work is protected by U. S. Copyright Law. Unauthorized use including reproduction for redistribution requires the permission of the copyright holder. For more information, please contact scholarsmine@mst.edu. Personal computing for the visually impaired PC Resident Driver Software Bruce M. McMillin Patricia Y. Mc Millin As with foreign languages, direct translations- say, into sound or touch-often don’t work - - - magine it’s the first day of a new semester. You are sitting in your laboratory section in front of a PC (per- sonal computer) and a stu- dent walks in with a white cane. This person may be totally blind, able to see light, partially sighted, or just legally blind. Still he or she is in col- lege, just like you. The only differ- ence is that this person cannot in- teract with the world in exactly the same way you do. Technology can facilitate this in- teraction. Often, technological aids for the physically challenged seem to evolve from disciplines other than engineering. Indeed, require-. ments for such systems may be generated from the social sciences, education, and rehabilitation fields. However, the engineer is responsi- ble for interpreting and implement- ing these requirements. This article will provide just such a set of engi- neering requirements for technolog- ical solutions for visually impaired persons. But, perhaps more impor- tantly, it will show how engineering techniques are used in the “human oriented” sciences. The major difficulty a visually im- paired person must overcome in a vi- sually oriented world is the problem of interacting with that world. Tradi- tional media, such as textbooks and handouts, are useless. The informa- tion must be made available in a spe- cial tactile language called Braille or it must be available in voice (either on tape or read out loud). If we have control over the original format of the information, then disseminating the information into these forms be- comes easier. A particularly interest- ing problem and solution arises when the original format is stored in a per- sonal computer. As it stands, the ma- terial isn’t terribly useful to someone who can’t see. The output appears silently on a video screen, and with- out someone there to read it, there is no way for the visually impaired to obtain the information present. Data entry, in its abstract form, seems to present no problem. Most visually impaired people know how to type on a typewriter keyboard at a very early age. But anticipating all the possible contingencies-for ex- ample, try invoking a spreadsheet or logging onto a mainframe with no feedback-is very, very tough. Feedback is the fundamental problem for operating a personal computer. Feedback is normally by sight. When sight is not available, feedback must take other forms. The conversion of printed text to an out- put form understandable by the vi- sually impaired generally involves a lot of manual labor. However, con- verting computer screen text can be accomplished in an automated fashion. Many inexpensive hardware devices exist that can synthesize speech. Other hardware can pro- duce tactile output. Linking these to digitally stored data eliminates any manual intervention. Since they have the necessary feedback available, a visually impaired user may use a machine without any external help. Figure 1 depicts the physical rela- tionship between the PC and various specialized hardware devices. Realize that hardware is not a magic box. Hardware and software must cooperate to provide a mean- ingful interface. Two important as- pects to consider are meaningful in- put and meaningful output. Figure 2 depicts the possibilities for each. Traditional output techniques Tactile output has been the main- stay of written communication for the visually impaired for over 100 years. The Braille alphabet consists of Braille cells each containing a fixed array of six positions numbered one thru six. Each position or dot is either raised or not (binary). Thus, there are 26 or 64 possible combina- tions. Figure 3a depicts the configu- Fig 1 .  Re1a:ionshiD between PC hardware Braille Printer components / - 7  Voice Unit 17 MAY 1989 0278-664818910005-0017$01 .OO C 1989 IEEE Feed back hi t t t t 1 Fl Fig 2 lnput and outpot requireirients Magnification ration of the Braille cell. The dots are imprinted on heavy stock and read by touch. The Braille alphabet is shown in Figure 3b. You may have noticed Braille in most public eleva- tors. It takes practice to train one’s sense of touch but, once mastered, it is a valuable skill. Since there are 63 possibilities (blank is not a valid symbol other than for delimiting purposes), each of the 26 letters of the alphabet is assigned to a particular configura- tion. For example, the letter “0” is formed by raising dots 1-3-5. The remainder of the configurations are assigned to punctuation, commonly used pairs of letters, and common words. Certain Braille cells are used as prefix codes to indicate different characters. For example, the num- ber sign prefix (3-4-5-6) used with a letter indicates a string of numbers and a letter sign prefix switches back to letter interpretation. Braille, however, is not a sim- ple transformation from character to Braille cell. To save space in the resulting text, certain cell configu- rations take on a different mean- ing based on context. The letter “k,” for instance, also indicates the word “knowledge” if it appears alone in a sentence. The combination of let- ters “w” and “d” denotes the word “would.” Even with these abbrevi- ations though, Braille texts can fill rooms. Computer input Input can take several forms. The most common form is natural lan- guage text entered from a standard typewriter keyboard. This type of input requires no special hardware. Since touch typists do not look at the keyboard, there is no learning curve for most people. A second alternative is to use tactile input. A Braillewriter is a mechanical device which formulates This woman is reading the screen with a product called Optacon (Optical Tactile Converter), conceived by / € E €  Life Fellow John G i invi l l  A s  the lens module moves across the image of a character, it converts the shape of the hght onto a tactile array of vibrating rods, which can be scanned by the touch of a finger Telesensory Systems, Inc 18 IEEE POTENTIALS Braille cells directly. The device con- sists of six keys, one for each dot of the cell and a space bar. To print the letter “g,” keys 1-2-4-6 are depressed simultaneously. In a me- chanical device, these keys are con- nected to hammers which make in- dentations in the paper. While this action may seem tedious, an accom- plished brailler is amazingly fast. A simple data structure can be used to store Braille cells (since each Braille cell is essentially a bit mask, each cell can be stored as a 6 bit integer). A final alternative, one used for input and display of already printed texts, is the optical scanner. Scanned characters from a printed page are recognized and stored character by character. They can then be dis- played by any of the standard output methods described in this paper. Computer output and feedback The output and feedback func- tions have roughly the same require- ments with respect to interactive us- age. Feedback can be either voice or tactile. For purely visually im- paired users, there is no requirement for voice input of text. A first ap- proximation to voice output would be to echo each character as it is typed or displayed. This may seem like a good idea until you try to listen to it. A continuous stream of letters becomes just so much noise. (Try it, have a friend read this last sentence out loud to you a letter at a time.) Thus, the output software must have some intelligence. Words may be parsed by sur- rounding spaces. The word itself, in a first attempt, may be pronounced by echoing the individual sounds together. This is fine for a word such as “hat” in which the mor- phemes (a meaningful speech unit with no smaller parts) used for pro- nunciation is easily obtainable from the word, itself. However, a word such as “technology” (pronounced tek-nol-e-ji) causes an obvious prob- lem. The software must be able to understand the typewritten word and pronounce it correctly using a com- bination of phonetic rules and dictio- naries. Even with correct pronunciation based on words alone, the resulting output may be incorrect. Consider words whose pronunciation changes with the context of their usage such as ‘‘live’’ (“I live in the city” and “He’s a live wire”). Another prob- lem is homonyms, words that sound alike but mean different things (e.g., character word sentence or paragraph) “boar” and “bore”). To a lesser ex- tent, the same problem is seen in spelling checkers with words that are spelled correctly but used incor- rectly. What is necessary is a pro- nunciation system that interprets the word in the context of the sentence. This discussion on pronunciation has assumed that the text is in nat- ural language (i.e., English). What about the verbalization of a pro- gram? In most programming lan- guages, acronyms and special sym- bols dominate program code. In the C language, comments are denoted by I* and * I .  Do we want to burden the listener with these noise words? How about parsing words by spaces? This idea no longer works when given the C language statement, for (i = 1; i < MAX; i ++). The speech generator must understand the dc- limiters of the particular language. In English, the delimiters are spaces. In programming languages, the delim- iters have a much wider range. Word pronunciation is not always desired. Under some circumstances character by character pronunciation may be desired. In checking spelling or in the use of acronyms, individual characters must be made available. So an output device must be capable of switching between the two, per- haps dynamically. Tactile feedback in the form of Braille cells can be produced on special devices that formulate the Braille character via raised pins on a tactile grid. This method roughly mimics the way one uses a Braillewriter. It may be used both with Brailler input and with key- board input. Although with keyboard natural language input, the Braille generator should understand the lan- guage transformations noted in our discussion of the Braille language. Again, this consideration is for the same reason we don’t want to echo each character with voice. Complicated screen formats pose another problem. We want infor- mational messages to be heard, but screen formatting presented to a sighted user may need to be silenced. These requirements dictate an inte- grated hardware, software, and ap- plication package solution. Simply hooking a voice module capable of word, or even special language, parsing is not sufficient. Any menu driven application would produce so much noise for every screen dis- played that listening to it all the time would soon result in discarding that package. For a sighted user, this does not present a problem, as a sighted user simply ignores these extraneous messages. Another task that is not covered by simple word feedback is the need to review what exists on the screen or in a file. This review cannot be brute force, i.e., every word on the screen is spoken when a new screen is displayed. Imaging using an edi- tor to locate a word. When the word is found, only that word and its sur- rounding context is important. The MAY 1989 19 Fig. 3.3. The Braille cell. Fig. 3b. Some common Braille symbols. 2o O5 I Letters & words based on context e e e  e e  e e e  m e  Ae b C b E F  But can do every from J K L  I just knowledge like I G H  go have em e e  e em e e  e e e e e e e e  e e  e e e  e e e e e  e e e M N O P Q R S T  more not people quite rather SO that e e e  e e  e e e e e e  e e (Preceded by numbersign) e. e Numbers w will it you as e e e  e e e  e e  e em e e e  e e  e e  3 4 5 6 e e  e e  e e  e e  9 0 e e e  e e e e  e e  e e  e e  e e e e  e e e e e while would could (wh, i, I, e) ( w  d) (G d) e e  e e e  1 e me e me e e  7 e e  e e  me e e  e form (for, m) e e  e e  e e  e 9992 e e e e e  e e  u v  us very e e  e e  2 e e  e e  e me e e  8 e a  e e  e e e  e m  Per (P? er) e e e  e e  e e today 4 other text on the screen is largely noise and ignored by the eye. For vocalization of text, the reduction of the noise words on the screen is equally, if not more, important than for visual display. The process of moving through a file of spoken text is called screen review. Screen review functions are basically the same as the cursor movement keys in an editor. Some packages provide the screen review function integrated with the editor while some packages provide it in- dependently. Clearly, the prior ap- proach is advantageous if for no other reason than to reduce the num- ber of keys that need be remem- bered. Still other systems solve this problem by providing a separate keypad for the screen reader func- tions. In any case, the functionality required is the ability to move the focus of what is spoken up a line, down a line, right, left, and so forth. Windows present an interesting problem for screen review function- ality. Clearly the currently active window should be the primary fo- cus. However, what about activity that occurs asynchronously in other windows? Should the current screen review be interrupted to service an- other window? If so, how do we do this in a way that is not distracting? Furthermore, how does a visually impaired user switch between win- dows? These are unanswered ques- tions. Perhaps by now you expect ev- ery output solution to require some specialized hardware and software. For the partially sighted user though, simply using large print may suf- fice for output. Most type is 10 or 12 point. Large print may be 18 or 20 point. It is relatively easy using most graphics hardware to simply produce enlarged characters on the CRT screen. Alternatively, a fresnel lens may be placed over a standard CRT screen. Still, another possibil- ity is to use a closed circuit TV that can read both CRT screens as well as print. Modern desktop laser print- ers can produce arbitrarily large text using standard word processing soft- ware. A further advantage is that when a document has been proof- read and is in its final form, a sim- ple printing control change reduces the output down to “acceptable size” for the non-visually impaired reader. (Indeed, this document was printed in point size 20 during its develop- ment with the final version printed in typewriter font for transmittal to the publisher.) Existing aids There has been a virtual explo- sion in products for the visually im- paired. The availability of low-cost hardware has resulted in a balloon- ing cottage industry of packages and hardware. Rather than attempt to provide a taxonomy of devices and packages, we list several sources for further information. The book Com- puter Equipment & Aids for the Blind and Visually Impaired by CCVI Pub- lishing, New York, 1985 provides just such a taxonomy, as of 1985, of devices and software for the vi- sually impaired. IBM maintains the National Support Center for Per- sons with Disabilities as a clear- inghouse for both IBM and non- IBM technologies available to the physically challenged. They can be reached at 1-(800j-IBM-2133. On the USENET electronic news sys- tem, the group misc.handicap has ongoing discussions on the suitabil- ity of various technologies. Ask your system manager how to access this bulletin board. About the authors Bruce McMillin is assistant pro- fessor of computer science at the University of Missouri at Rolla. His current research interests include fault-tolerance, multiprocessing sys- tems, parallel algorithms, software engineering, and distributed systems theory. He is a member of IEEE, ACM, and SIAM. Patricia McMillin is completing a B.A. from Michigan State Univer- sity and will pursue a master’s de- gree in education for the visually impaired. She also has extensive ex- perience with numerous aids for the visually impaired. 0 20 IEEE POTENTIALS 

Personal Computing for the Visually Impaired

https://scholarsmine.mst.edu/cgi/viewcontent.cgi?article=1269&context=comsci_facwork

Personal Computing for the Visually Impaired

Abstract

Similar works

Full text

Available Versions

Missouri University of Science and Technology (Missouri S&T): Scholars' Mine