RE: screen-reader versus self-voicing app (was: Re: Screen-reader behaviour)

+Gregory's summary though written in a nice logical progression
starts with a couple of strong assumptions which leads to the
conclusions he arrives at.

I've used a self-voicing app -- Emacspeak -- for the last 12
years, and everyone here who knows me knows that I am more than a
casual computer user.

So Gregory -- in future, when you write something like this,
clearly document your opening assumption.

In this particular case, your opening assumptions were:

A) User is victim to a locked-down "user environment"
B) You confused "operating system" with "user environment".

In the Linux / Emacspeak case, neither (A) and (B)  are true,
which consequently debunks most of what you wrote ---

Lisa Seeman writes:
 > 
 >  Gregory wrote: self-voicing apps have their place in the overall scheme of
 > things  but they are NOT substitutes for screen readers.
 > 
 > Two places were they have an important role is for people with learning or
 > language disabilities. Another use is for people who do not have their own
 > computer, and can use firevox on a shared computer, such as the library
 > (which may not be prepared to install a bulky program such as Jaws but will
 > be prepared to help someone get started). Also as people develop vision
 > problem (such as associated with diabetes and aging) may often use the self
 > voicing apps for reading print. This group do not need a screen reader for
 > selecting icons at the start up but  they may not want to, or even be able
 > to, manage a screen reader (which take quite good memory skills).  Another
 > huge group who need to be taken into account are third word computer users
 > who may be unable to afford a screen reader or may not read well. 
 > 
 > So they are not  a substitutes for screen readers  but  self-voicing apps
 > have an important place in the world.
 > 
 > All the best
 > 
 > Lisa 
 > 
 > 
 >  
 > 
 > 
 > 
 > -----Original Message-----
 > From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On Behalf
 > Of Gregory J. Rosmaita
 > Sent: Monday, September 10, 2007 9:29 PM
 > To: Charles McCathieNevile; Sander Tekelenburg; public-html@w3.org;
 > wai-xtech@w3.org
 > Subject: screen-reader versus self-voicing app (was: Re: Screen-reader
 > behaviour)
 > 
 > 
 > aloha!
 > 
 > as a screen-reader user, let me attempt to explain why there is no
 > groundswell of support for "self-voicing" applications by those dependent
 > upon speech output...
 > 
 > 1) unavoidable black holes:
 > self-voicing applications cannot replace a dedicated screen reader, for
 > self-voicing applications often cannot interpret key parts of the chrome,
 > espeically if the chrome does not reuse standard control sets for the OS on
 > which it is running -- download interfaces, view source interfaces (that
 > open up a new browser instance or tab), the ability to "browse" files to be
 > uploaded to a web site, etc. this is because the self-voicing application
 > exists solely to voice the application which is currently running;
 > 
 > 2) one can put one's screen-reader into "sleep" mode for a particular app,
 > so that the self-voicing app doesn't conflict with the screen reader, but
 > this often leads to unexpected and undesired results;
 > 
 > for example, in order to use FireVox, i set JAWS to become inactive whenever
 > FireVox is loaded -- however, since FireVox is an extension, and not a
 > seperate app, i can no longer run FireFox with a screen reader, because the
 > screen reader cannot differentiate between the synonymic executable files
 > when invoked, and therefore, disables screen reader interaction when a
 > partucular executable is loaded;
 > 
 > 3) self-voicing apps can still conflict with a scren reader due to events
 > from the self-voicing apps firing whilst one is in a plain text document
 > checking one's credit card or banking information;  which is also why
 > self-voicing applications have limited appeal and why they CANNOT be run
 > without a screen reader -- if i am using a self-voicing app, once i switch
 > tasks, i have no wey of knowing what is currently running -- even when doing
 > something as "trivial" as copying the contents of a page to the clipboard
 > and pasting it to an empty plain text document -- without a screen-reader at
 > the ready to "awaken" when the user switches from the self-voicing app, the
 > speech-dependent user is left without a means of ensuring that previous
 > information has not been overwritten, nor what directory into which the file
 > is going to be saved, nor access to any system calls ("do you want to
 > overwrite..." or "error - nothing selected"
 > 
 > self-voicing apps have their place in the overall scheme of things, but they
 > are NOT substitutes for screen readers; what we should be concentrating upon
 > is NOT how does current assisstive technology handle current markup, but how
 > to enable assisstive technology to handle markup better, by providing more
 > explicit association patterns and as much semantic information as possible
 > 
 > THAT is the goal -- to improve bi-directional communication between
 > applications, in this case, between user agents and screen readers -- not to
 > critique the current state of support -- it must ALSO be realized that HTML
 > 4.01 did not proclaim that it had addressed all accessibility problems, only
 > those that emergency triage units identified as the most crucial problems in
 > the late nineteen-nineties -- it was NEVER intended to be the be all or end
 > all in web accessibility, but an effort to provide a means of breaching
 > perceptual black holes and the sort of device dependence and modality
 > dependence that breaks assisstive technologies...  even for a self-voicing
 > app to work well, it must rely upon the semantics built into the markup
 > language it supports...
 > 
 > this is why this whole thread is a red herring in my opinion -- we cannot
 > "break" what was done in the past to promote accessibility, useability,
 > internationalization and device independence, nor should we be bound to
 > putting old wine into new bottles -- where superior mechanisms are
 > available, they should be implemented, but those mechanisms implemented in
 > HTML 4.01 specifically for accessibility, device independence and
 > internationalization MUST be supported as part of the "backwards
 > compatibility" principle, hence my suggested verbiage for the design
 > principle document:
 > 
 >    "Browsers should retain residual markup designed for a specific 
 >    purpose, such as accessibility. internationalization or device 
 >    independence. Simply because new technologies and superior 
 >    mechanisms have been identified, not all of them have been 
 >    implemented. Moreover, disabled users are more likely to be 
 >    users of "legacy technology" because it is the only technology 
 >    that interacts correctly with third-party assistive technologies"
 > 
 > or words to that effect...
 > 
 > gregory.
 > 
 > 
 > --
 > "He who lives on Hope, dies farting."
 >   -- Benjamin Franklin, Poor Richard's Almanack
 > --
 > Gregory J. Rosmaita, unagi69@concentric.net Camera Obscura:
 > http://www.hicom.net/~oedipus/
 > 
 > 
 > 
 > 

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Tuesday, 11 September 2007 18:23:25 UTC