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/

Received on Monday, 10 September 2007 18:29:45 UTC