W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2000

Comments on draft

From: Charles McCathieNevile <charles@w3.org>
Date: Tue, 11 Jul 2000 01:16:20 -0400 (EDT)
To: WAI UA group <w3c-wai-ua@w3.org>
Message-ID: <Pine.LNX.4.20.0007100843460.14670-200000@tux.w3.org>
Attached as HTML (easy way to deal with this is to look at the archives)
and included below as text

W3C Working Draft 7 July 2000

1. Introduction

   [INS: CMN This section is good :INS]
    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]
   Not every checkpoint or guideline is applicable to every user agent.
   Generally, a user agent must adhere to checkpoints that ensure
   accessibility of functionalities that it offers to users and it must
   implement required functionalities [1]natively. If the user agent
   supports keyboard input, it must support accessible keyboard input. If
   the user agent supports images, it must ensure access to each image or
   an equivalent alternative specified by the author. If a user agent
   supports style sheets, it must implement the accessibility features of
   the style sheet language. If the user agent supports frames, it must
   ensure access to frame alternatives specified by the author. In short,
   if a user agent offers a functionality, it must ensure that people
   with disabilities have access to that functionality or an equivalent
   Not all user agents support every content type, markup language
   feature, input or output device interface, etc. When a content type,
   feature, or device interface is not supported, checkpoints with
   requirements related to it do not apply to the user agent. Thus, if a
   user agent supports style sheets at all, all checkpoints related to
   style sheet accessibility apply. If a user agent does not support
   style sheets at all, the checkpoints do not apply.
2. User agent accessibility guidelines

   Checkpoints for communication with other software:
   1.1 Ensure that every functionality available through the [2]user
          interface is also available through every input [3]API
          implemented by the user agent. This checkpoint does not require
          developers to reimplement the input methods associated with the
          keyboard, pointing device, voice, and other input [4]APIs. The
          device-independence required by this checkpoint applies to the
          functionalities described by the other checkpoints in this
          document (e.g., installation, documentation, [5]user agent user
          interface configuration, etc.). [Priority 1]
   1.2 Use the [6]standard input and output device APIs of the operating
          system. Do not bypass the standard output [7]APIs when
          rendering information. [Priority 1]
   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]
  Guideline 3. Allow the user to turn off rendering or stop behavior that may
  reduce accessibility.
   Checkpoints for content accessibility:
   3.3 Allow the user to [10]configure the user agent to render animated
          or blinking text as motionless text. [Priority 1]
   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]
  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]
   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]
   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]
  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]
   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]
   5.4 Provide programmatic read and write access to [20]user agent user
          interface controls using standard [21]APIs (e.g.,
          platform-independent APIs such as the W3C DOM, standard APIs
          for the operating system, and conventions for programming
          languages, plug-ins, virtual machine environments, etc.)
          [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]

References deleted.

Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053
Postal: GPO Box 2476V, Melbourne 3001,  Australia 

Received on Tuesday, 11 July 2000 01:16:22 UTC

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