Re: forwarded message from Jason White

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Wed, 17 Mar 1999, Jason White wrote:

> In answer to Brian's question, the issue arose in the context of a
> discussion concerning the general utility of a conventional "screen
> reader" approach, in which the braille/auditory interface is derived from
> monitoring the visual u i, by contrast with the benefits to be gained from
> enhancing the underlying software environment such that non-visual
> interfaces can take advantage of the semantic and structural distinctions
> reflected in the internal data representations maintained by applications.
> Emacspeak exemplifies, very successfully, the latter strategy. 

While this was well thought out and clearly stated you are leaving out
the fact that while emacspeak does work well for the software written
spicificly for emacs it doesn't do well at all with aplications written
for real world Shell users.  Add to that fact that some Unix
administrators don't even install Emacs do to its size this limits blind
users greatly.  In fact the University I am currently attending refuses
to put the Emacs program on for me because their hardware is limited.  I
have to use my own system and hook in through the network.  
argued > that priority should be given to influencing the development of
> open-source software environments to facilitate a separation of
> application functionality from visual presentation in ways that permit
> braille and auditory interfaces to gain access, via generic means wherever
> possible, to the semantic content required to ensure a high quality of
> interaction. In reply, it was urged that good results could be achieved by
> traditional "screen reading" methods and the writing of scripts that would
> monitor the visual interface and react in specified ways to predefined
> patterns in the visual presentation. It became clear in the course of this
> discussion that some of the participants considered that importance should
> be attached to the development of a text-based screen reader for the Linux
> console which would employ scripts and macros in the manner suggested. By
> way of rejoinder, I reiterated my reservations concerning the limits of
> the "screen reader" concept and argued that, in any case, given that the X
> Window System supports both text-based and graphical applications, and
> recognising that UltraSonix employs essentially the design described
> above, consisting, as it does, in core screen reader functions with the
> details of the interface being controlled by scripts, there was no need
> for a separate screen reader to be developed. Rather, efforts along
> traditional screen reader lines should be concentrated on UltraSonix,

This is the point where my blood realy boils.  I have used Msdos programs
for 8 years with these traditional screen readers and my screen reader
employees AI to do a lot of what everyone is raving about EMacspeak.  I
read colums in a word processor fine no matter their size width or
content.  I can read what the colum header is or what is in the colum with
a push of the button I can see the date I am in the in a calender and I am
not talking about the number 1 I am talking entire date.  Things that
Emacspeak can do fine yes but so can these older screen readers.  What is
the difference?  The difference is in order to learn Emacspeak you have to
be willing to learn emacs.  You shouldn't have to learn emacs to be able
to use every aplication on the system nor should you have to install
Xwindows to use a shell prompt.  Again your suggestion of jumping on the
Ultra sonics band wagon locks us into you either use Emacs or you use
Xwindows.  I use the shell currently with Asap and have been for 4 1/2
years.  my pine doesn't talk to much my clients for my job work fine
something that doesn't happen in Emacspeak..  I don't have to use Xwin and
this is all done with one of those waisted speech programs you are jumping
so badly.  I would like to know what screen reader you used in the MsDos
environment that ticked you off so badly I would bet it would be Jaws or
Vocal-eyes judging by your comments because nothing you ahve said here
fits my screen reader.

I want to add that the screen reader that I have been using takes a total
of 54k in memory if it was coded in 'c' it would probably take around 200k
in memory and be able to handle every normal shell program perfectly.
Including making sure pine don't talk to mucha nd the ability to read
colums correctly.  I think Speak-up and even SvlPro and a new commercial
one I just heard of in the news groups which will be coming out soon are
headed in the right direction.  While Emacspeak will for sure be around
for a long long time and may in the future benifit itself in having other
screen readers around it is not and should not be the method everyone
follows.  That goes the same for an Xwin solution god knows I don't want
to use Xwin anymore than I have to.

Ken /whistler

[Index of Archives]     [Linux for the Blind]     [Fedora]     [Kernel List]     [Red Hat Install]     [Red Hat Watch List]     [Red Hat Development]     [Gimp]     [Yosemite News]     [Big List of Linux Books]