- 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