- 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 alternative. 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
Attachments
- TEXT/html attachment: comments.html
Received on Tuesday, 11 July 2000 01:16:22 UTC