Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!bunker!wtm
From: campbell%hpdmd48@hplabs.HP.COM (Gary Campbell)
Newsgroups: misc.handicap
Subject: Re: Text to Speech
Message-ID: <17296@bunker.UUCP>
Date: 31 Jan 91 03:21:48 GMT
References: <17076@bunker.UUCP>
Sender: wtm@bunker.UUCP
Reply-To: campbell%hpdmd48@hplabs.HP.COM (Gary Campbell)
Distribution: misc
Lines: 93
Approved: wtm@bunker.UUCP
Fidonet: Blink Talk Conference

Index Number: 13283

JS5L@andrew.cmu.edu (Jack Stein) writes:

First, thanks for asking!

>  b. We have a willing user who is blind and is a programmer that  wants
>to help us with  design, beta testing.
>  c. We are going to contact the local chapter of the Pittsburgh Blind
>Association for additonal input.

Sounds good-- I'm not familiar with this organization, but, as I said,
I'm glad to see you looking for input.  I hope it's changing, but there
have been too many times in the past when people went off into
development efforts without doing this!  

>1. Are there products on the market that do similiar things that are
>well established and used by blind people  with pc/ps-2?

There are a few programs especially designed for use with speech, but
most people use off the shelf programs and concentrate on getting the
features in a screen reader program necessary to use the software.
There are, however, things that a software writer can do to make the
program more useable by someone using speech.  The kind of interface you
describe is often difficult to use, and the proper adaptations could be
very appropriate.  I would suggest that you have a look at some current
screen readers (there are demos for many, and Pitsburg is the home of
the BlinkLink Fidonet conference to which this message should be gated,
so I think you should be in good shape there).  I also suggest that you
approach the problemin a way that doesn't lock you into DecTalk, since
that is a very expensive solution and there are many less expensive ones
out there that will do the job quite nicely (many feel better!).

>2. Are there certain conventions/established guidelines for the way
>software should interface to a blind user?
>3. Are there keyboards available with braille on them for use by blind people?

I don't see a need for this, except maybe for a workstation used by many
people who have little familiarity with PCs.  If you do have this
situation, I think that a braille key chart beside the computer should
suffice.  You might want to put little dots on the f and j keys or
something, but I haven't wanted that enough to bother with it on either
of my PCs.

>4. What  kind of groups or organizations are available for us to contact
>for input/discussion, especially schools for blind that have had to deal
>with integration of PC/PS-2 into the  curriculum.

There are a couple of national organizations for the blind-- the
American Council for the Blind andthe National Federation of the Blind,
who, I believe, have computer groups.  However, as I said, there are a
lot of users, and a few speech system writers on the BlinkLink Fidonet
conference who should get this message.  I believe that that conference
started in Pitsburg, so there should be a lot of info available to you
to get you hooked up with local people who can give you input.

Below are some comments I wrote in answer to another similar message
which I hope are helpful:

 subject: Re: Synthesizer interfacing
 in-Reply-To: article <14296@bunker.UUCP> of Thu, 20 Sep 1990 15:59:02 GMT

I don't remember seeing your original message, but as everyone is
saying, you want to make the program easy to use with screen readers,
not directly interface with the synthesizer.  Most screen readers do
not speak what is directly written to video memory, although some of the
new ones have a feature allowing speaking of an area of the screen that
changes, but they do speak what is written to BIOS interrupt 10h, and
therefore also what is written to DOS.  Therefore, intelligent choice of
how you write to the screen can make a program easier to use with
speech.  Write things like prompts and error messages to BIOS and screen
updates to the screen directly.

Screen readers also usually have the ability to "follow" the cursor.
When you do a "cursor down" it waits for the program to move the cursor
and then says the line the cursor is on by grabbing it from video
memory.  When you do a CTL-cursor-right it says the word the cursor ends
up on.  Many readers also give some capability of following a light bar,
but it is often not as flexible as the following of the regular cursor.
If you are using a light bar and not using the cursor for anything, put
the cursor with the light bar instead of parking it in some useless
place like the corner of the screen.  Also, if you pop a window up on
the screen, blank the stuff on either side of it out so that a "say
line" function reads the line of the menu only, and not the background
stuff that you don't care about anyway while you are in the menu.

Also, bitmap screens are not accessible by present-day screen readers,
so if you are using a bitmap screen, you will have to write your own
interface to the synthesizer.

Hope this helps.
--
Gary Campbell