- From: T.V Raman <raman@google.com>
- Date: Tue, 11 Sep 2007 11:22:25 -0700
- To: lisa@ubaccess.com
- Cc: unagi69@concentric.net, chaals@opera.com, st@isoc.nl, public-html@w3.org, wai-xtech@w3.org
+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:26 UTC