comments on guidelines

Very thorough job... difficult to find things to comment on, but here are a 
few.

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

LRK: IMPORTANT
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 
presentation".
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.

Len


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

kasday@acm.org
http://astro.temple.edu/~kasday

(215) 204-2247 (voice)
(800) 750-7428 (TTY)

Received on Wednesday, 1 December 1999 11:26:01 UTC