- From: Lisa Seeman <lisa@ubaccess.com>
- Date: Tue, 11 Sep 2007 09:26:04 +0300
- To: unagi69@concentric.net, 'Charles McCathieNevile' <chaals@opera.com>, 'Sander Tekelenburg' <st@isoc.nl>, public-html@w3.org, wai-xtech@w3.org
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/
Received on Tuesday, 11 September 2007 06:27:04 UTC