W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1999

comments on guidelines

From: Leonard R. Kasday <kasday@acm.org>
Date: Wed, 01 Dec 1999 09:49:02 -0500
Message-Id: <>
To: w3c-wai-ua@w3.org
Very thorough job... difficult to find things to comment on, but here are a 

BTW, these are personal comments and not necessarily represent those of my 
employer or of ER-IG.

My comments preceded by LRK, and follow brief excerpts from the document.

 > 1.2 Use the standard input and output device APIs of the operating system.
 > [Priority 1]
 >      For example, do not directly manipulate the memory associated with

LRK: I think this is overly restrictive if the UA has accessibility 
built-in.  For example, a browser with built in speech output of all text 
on the screen.  In this case it is not absolutely necessary to give 
standard operating system access to the text, so I would suggest 
downgrading to Priority 2 or 3 (depending on how important it is to have 
Braille output).  This is a real possibility for pocket sized wireless web 
acccess devices, for which speech output is more practical than a tiny 
screen, especially when driving.  This comment also applies to 1.5 (ensure 
all messages available thru API).

 > 2.2 If more than one alternative equivalent is available for content, allow
 > the user to choose from among the alternatives. This includes the choice of
 > viewing no alternatives. [Priority 1]

LRK: I suggest you add to the examples here a general ability to control 
"level of detail".  For example, choice of following modes:
1. Speaking only ALT text, with means to speak LONGDESC on image by image basis
2. Speak ALT text and LONGDESC for all IMAGES

 > 2.5 Allow the user to specify that continuous equivalent tracks (e.g.,
 > closed captions, auditory descriptions, video of sign language, etc.) be
 > rendered at the same time as audio and video tracks. [Priority 1]

LRK: Suggest you clarify: just "at the same time" but interleaved according 
to e.g. SMIL code.

 > Guideline 4. Ensure user control over styles

Authors can associate a meaning with a style (e.g. "new", "sale", 
"obsolete"), but there is presently no standard way to specify what it 
is.  As a workaround, the UA should give access to the name of the 
style.  At the same time, the WAG guidelines should tell authors to use 
meaningful names, like "sale", "new", etc..

 > Checkpoints for audio:
 > 4.11 Allow the user to control audio playback rate. [Priority 1]
 >      Techniques for checkpoint 4.11

LRK: Add as priority 2 or 3: ability to change rate without changing pitch 
(there are well known methods for this).

 > 4.16 Allow the user to control synthesized speech pitch, gender, and other
 > articulation characteristics. [Priority 2]
 > 6.1 Implement the accessibility features of supported specifications
 > (markup languages, style sheet languages, metadata languages, graphics
 > formats, etc.). [Priority 1]

LRK: Mention audio style sheet explicitly.

LRK: There's another important feature that should be added.
"Do not constrain the accessible output by constraints of the existing 
For example, even though a sighted user has to explicitly scroll to see a 
page that is longer than a screen, a blind user should not have to worry 
about scrolling a "screenful" vertically.  Similarly, the blind user should 
not have to scroll horizontally if the display is wider than the physical 
screen, or scroll through selection lists a chunk at a a time.


Leonard R. Kasday, Ph.D.
Institute on Disabilities/UAP, and
Department of Electrical Engineering
Temple University
423 Ritter Annex, Philadelphia, PA 19122


(215) 204-2247 (voice)
(800) 750-7428 (TTY)
Received on Wednesday, 1 December 1999 11:26:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:24 UTC