Re: Comments on draft

Charles McCathieNevile wrote:
>
>     Checkpoint applicability
> 
>    [INS: CMN I am a bit concerned about the generality of this - it is
>    not clear in the guidelines what is a required functionality and what
>    is subject to applicability. In addition, or perhaps as a consequence,
>    it is not clear what a User Agent needs to support. For example,
>    should it be a requirement that a User Agent can render images, or
>    that a user can follow links, in order for the User Agent to be
>    accessible to people regardless of disability? In particular, this
>    would seem to allow a User Agent to conform on the basis that it
>    doesn't implement APIs, so those checkpoints are not applicable (and
>    similarly for other requirements). :INS]

[snipped applicability section]

> 
> 2. User agent accessibility guidelines
> 
>    1.3 Implement the [8]standard keyboard API of the operating system and
>           ensure that every functionality available through the user
>           interface is available through this API. This checkpoint always
>           applies on systems with a [9]standard keyboard API.
>           [Priority 1]
> 
>           [INS: CMN See my notes on applicability for my concerns with
>           this checkpoint :INS]

I'm not sure what your concerns are here. The wording of this checkpoint
was designed to make clear that "this checkpoint always applies on
systems with a standard keyboard API." 
 
>   Guideline 3. Allow the user to turn off rendering or stop behavior that may
>   reduce accessibility.
> 
>    3.4 Allow the user to [11]configure the user agent to render
>           animations or blinking images as motionless images.
>           [Priority 1]
> 
>           [INS: CMN It should be noted that these (especially the second)
>           are related to the checkpoints on control of video :INS]

I believe that when we're done, the checkpoints in Guideline 3 will 
be about configuration whether to run on loading. The checkpoints in G4
will be about control once loaded.

>   Guideline 4. Ensure user control of styles.
> 
>    Checkpoints for fonts and colors:
> 
>    4.1 Allow the user to [12]configure and control the size of text.
>           [DEL: If this is done by allowing the user to configure font
>           size, :DEL] make available the range of system font sizes.
>           [Priority 1]

Yes, I guess so. 
 
>    Checkpoints for visual and auditory presentations:
> 
>    4.5 Allow the user to slow the presentation rate of audio, video, and
>           animations. For a visual track, provide at least one setting
>           between 40% and 60% of the original speed. For a pre-recorded
>           auditory track including stand-alone audio presentations,
>           provide at least one setting between 75% - 80% of the original
>           speed. For a synchronized multimedia presentation where the
>           visual track may be slowed from 100% to to 80% of its original
>           speed, synchronize the visual and auditory tracks. Below 80%,
>           the user agent is not required to render the auditory track.
>           [Priority 1]
> 
>           [INS: CMN So if the User Agent only includes a video slowed to
>           50% it is not necessary to provide an audio that is
>           synchronised. Do we mean this (I can live with it). :INS]

As I recall, that is our intention.

>    Checkpoints for user interface accessibility:
> 
>    4.16 Allow the user to [13]configure the user agent so that after one
>           [14]viewport is open, no other viewports open except as the
>           result of explicit user request. [Priority 2]
> 
>           [INS: CMN The frames case is an interesting one. Not presenting
>           frames can benefit people who have difficulty in using them,
>           and would prefer to use a noframes version, but can also
>           disorient people :INS]

Note that this checkpoint does not require user agents to suppress
the rendering of individual frames. If a viewport opens to render
a frameset, then the user can request that no other viewports open.
The checkpoint does not require the user agent to render fewer than
all the frames in a frameset.

Access to NOFRAMES is covered by 2.1 (access to all content) and
I believe also 2.3 (easy access to alternative content). I think
we should indicate near checkpoint 2.3 (e.g., the techniques) that
NOFRAMES is an indicator of alternative content and user agents
should allow users to have easy access to it in lieu of the frame
rendering. Some user agents give access to NOFRAMES with a 
"turn off support for frames" setting.

>   Guideline 5. Observe system conventions and standard interfaces.
> 
>    Checkpoints for communication with other software:
> 
>    5.1 Provide programmatic read access to HTML and XML [15]content by
>           conforming to the W3C Document Object Model (DOM) Level 2 Core
>           and HTML modules and exporting the interfaces they define.
>           [Priority 1]
> 
>           [INS: CMN These three checkpoints could be combined (with a
>           special case if necessary for DOM. Basically they require
>           standard APIs (again) and in particular the implementation of
>           applicable parts of DOM (again - see "use applicable W3C
>           technologies) :INS]

Please propose text.
 
>    5.2 If the user can modify HTML and XML [16]content through the
>           [17]user interface, provide the same functionality
>           programmatically by conforming to the W3C Document Object Model
>           (DOM) Level 2 Core and HTML modules and exporting the
>           interfaces they define. [Priority 1]
> 
>    5.3 For markup languages other than HTML and XML, provide programmatic
>           access to [18]content using standard [19]APIs (e.g.,
>           platform-independent APIs and standard APIs for the operating
>           system). [Priority 1]
> 
>   Guideline 7. Provide navigation mechanisms.
> 
>    Checkpoints for user interface accessibility:
> 
>    7.2 For user agents that offer a browsing history mechanism, when the
>           user returns to a previous viewport, restore the [22]point of
>           regard in the [23]viewport. [Priority 1]
> 
>           [INS: CMN The question of having a history mechanism is already
>           currently satisfied by the applcability rule isn't it? :INS]

Yes, I think so. So the checkpoint could read (with an additional
clarification):

   For each state in a viewport's browsing history, restore
   the point of regard associated with that state when the user
   returns to it in the viewport.

 - Ian

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Friday, 21 July 2000 12:00:33 UTC