Re: writing for a handicapped audience

[Jesse Kaysen <jesse -at- MAILBAG -dot- COM>]

Yes, Sue Ellen, I've written for audio readers -- those using audio
tape and those using speech output from the computer. BTW, in addition
to people with vision impairments, or people who are blind, the
potential "handicapped" audience includes people with limited hand
dexterity, who may be able to read regular print but can't turn the
pages of a book.

I was the lead tech writer at a publisher of large print,
voice-output, and braille translation software. I was responsible for
writing and producing large print, braille, and audio tape versions of
all our documentation and sales materials, and this helped me to
realize the peculiarities of each medium. I started out completely
innocent of these issues: in addition to the sage advice of two
co-workers who were expert braille, audiotape, and computer-screen
readers, customers offered their suggestions. I know of no reference
work on this issue, although Recording for the Blind's and the
National Braille Association's monographs on how to narrate (read
aloud) technical material did provide helpful background.

Braille and print readers have the same level of random access, but
audio readers--particularly on cassette--are at a distinct
disadvantage. Our documentation was "tone-indexed" to assist readers
in locating the start of each print page and each chapter. But an
audio tape index is a monstrous thing to use--it's just too serial.
Most audio readers have only one tape player, making  cassette
switching cumbersome. Our company was determined to provide 'hard
copy' instructional material, because our target audience was new
computer users. A new user with vision impairments trying to get
introductory information from on-line documentation must somehow have
already mastered the voice-output tools. _That_ bootstrap is long
enough to hang them!

Generous cross-references like "see chapter 8.2 for how to delete
files" would only generate massive frustration, so my documentation
tried to walk the fine line between repeating everything everywhere
and no x-refs at all. My solution was to *quickly* explain the
highlights of the reference, and then my x-refs more accurately could
be "more details on file deletion appear at chapter 8.2".

Unnumbered bulletted lists lose their punch when accessed serially, so
I wrote around them. EX:
The four errors you may encounter are
(bullet) Printer not found
(bullet) File not found
....and so forth.

Screen readers (the generic term for voice output software) vary in
how they pronounce punctuation, so when writing about a grep-like
replace function, I would both show  strings like "n^8" and describe
them in words "lowercase n, caret, digit eight." (And I'm not even
opening the door on the complex issues of braille translation, with
several different representations available for non-alphanumeric
characters.)

Tip of the iceberg, but a start

Jesse the K -- Madison Wisconsin USA -- <jesse -at- mailbag -dot- com>
====  consciousness: that annoying time between naps  =====

On 18 Nov 95, Sue Ellen Adkins <sea -at- netcom -dot- com> asked, in part
> I would expect visually impared readers to find on-line manuals more
> useful than books.  Are there factors tech writers need to consider
> when writing for disabled readers?  Has anyone done writing aimed at a
> handicapped audience?