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

Re: comments on guidelines

From: Ian Jacobs <ij@w3.org>
Date: Thu, 02 Dec 1999 23:31:10 -0500
Message-ID: <3847478E.EE132929@w3.org>
To: "Leonard R. Kasday" <kasday@ACM.org>
CC: w3c-wai-ua@w3.org
"Leonard R. Kasday" wrote:
> 
> 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. 

But in this case, the *standard* APIs for the system would be different
(or non-existent), wouldn't they?


> This comment also applies to 1.5 (ensure
> all messages available thru API).

Added as issue 150: Do APIs apply when the software is accessible 
on its own?

(I suspect that the answer will be that the UA still needs to 
make information available.)

http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#150
 
>  > 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

Good idea.
 
>  > 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.

Meaning: respect synchronization?
 
>  > 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.

This is probably covered by 2.1: ensure access to all content.

> 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).

Added as issue 151
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#151
 
>  > 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.

yes, in the techniques.
 
> 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.

Added as issue 152
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#152

Thanks Len!

 - Ian

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814
Cell:                        +1 917 450-8783
Received on Thursday, 2 December 1999 23:32:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:25 UTC