Proposed modification to Guideline 1 and Guideline 2
Background
The following proposal attempts to address a number of concerns
about Guidelines 1 and 2 that were raised by Marja Koivunen (refer to
Marja's message of 29 September 1999. See also
Marja's comments on Guidelines 1 and 2 upon which this proposal
is founded. It also takes into account
changes proposed by Rich Schwerdtfeger.
The goals of this proposal are the following:
- Ensure that it is clear how important the keyboard is
to accessibility. At the same time,
make sure that developers realize that the keyboard is not
the only solution to accessibility: certain functionalities
should be addressed in a larger context than keyboard alone.
- Clarify that in terms of the user interface, the user
needs to know what the current behavior is (e.g., keyboard
bindings), not whether the behavior initiated with the user
agent or author.
- Ensure that the user can interact with the user interface
in an output device-independent, not just input device-dependent
manner. Note. This does not imply that UAs
need to support every output device API, only that for supported
output device APIs, that all functionalities be available. For
instance, one must be able to get feedback about navigation
in a way that does not rely on a two-dimensional graphical rendering.
Why make this proposal now?
- I think we gain a lot at little cost.
- Marja has raised legitimate issues that were debated
on the list and merit resolution.
Notes on the proposal
- Reference document:
22 October draft
- All checkpoints of Guideline 2 are dispersed to Guidelines 1 and
11. There are no new checkpoints.
Checkpoints formerly numbered 1.3, 1.4, and 1.5 from the 22 October
draft have been subsumed by checkpoint 1.1.
- Checkpoint 6.1 reads:
Implement the standard input and output device APIs supported by
the operating system (e.g., mouse, keyboard, speech, etc.) [Priority
1]. It's a judgment call whether this should be in Guideline 6 (
conventions) or Guideline 1 (on input/output APIs). Supposing it is
dropped from Guideline 6, it appears here as checkpoint 1.3.
This was also a proposal from Rick, although he integrated it into
checkpoint 1.1.
- Note that 1.2 (active elements) is redundant with 1.1
(all functionalities). However, it is important enough to stand alone.
- Similarly, 1.3 (standard input/output) is redundant with 1.4
(support the keyboard) but 1.4 is important enough to stand alone.
- The rationale of G1 and G2 will have to be edited accordingly.
As part of emphasizing the importance of the keyboard to
accessibility, the pertinent prose would be retained in Guideline 1.
Summary of the fate of old checkpoints:
- Was 1.1 = Now 1.1
- Was 1.2 = Now 1.2
- Was 1.3 Subsumbed by 1.1
- Was 1.4 Subsumbed by 1.1
- Was 1.5 Subsumbed by 1.1
- Was 1.6 Generalized to all output information (not just
messages).
- Was 2.1 = Now 1.4
- Was 2.2 = Now 11.1
- Was 2.3 = Now 11.2
- Was 2.4 = Now 11.3
- Was 2.5 = Subsumed by 11.3
- Was 2.6 = Now 11.4
- Was 2.7 = Now 11.5
- Was 2.8 = Now 11.7
- Was 6.1 = Now 1.3
- Was 11.1 = Now 11.6
- Was 11.2 = Now 11.8
- 1.1 Ensure that all
functionalities offered through the user interface are available through
input device APIs
implemented by the user agent. Functionalities include installation
procedures, control of the user interface, access to documentation, and
configuration. [Priority 1]
- Note. Functionalities include being able to show,
hide, resize and move graphical viewports created by the user
agent.
- Note. The device-independence required by this
checkpoint applies to functionalities described by the other checkpoints
in this document unless otherwise stated by individual checkpoints.
- 1.2 Ensure that the user
can interact with all active
elements in a device
independent manner. [Priority 1]
- For example, ensure that the user can activate links of a client-side image
map in a device-independent manner (e.g., by making them available as
text links).
- 1.3 Support
standard input and output device APIs for the
operating system.
[Priority 1]
- Note. What is "standard" for a particular
environment will change over time. Today, for example,
the mouse and keyboard are standard in a graphical desktop
computer environment. Tomorrow, voice input and output may be
standard. For a small device, standard input may come
from a pen or keypad, and output through an LCD screen.
- 1.4 Ensure
that all functionalities offered through the user
interface are available through the standard keyboard API.
- 1.5 Ensure that information
output as part of operating the user agent is available through ouput device
APIs implemented by
the user agent. [Priority 1]
-
For instance, users must be able to operate the user agent without
relying on two-dimensional graphical output, cursor position, etc. User
agents must ensure that information about how much of a page or video
clip has been viewed is available through output device APIs. Proportional
navigation bars may provide this information visually, but the
information must be available to users relying on synthesized speech or
braille output.
- 11.1 Document the default
input configuration for the keyboard, graphical user interface,
voice commands, etc. [Priority 1]
- 11.2 Provide information to the
user about the current
input configuration for the keyboard, graphical user interface,
voice commands, etc. [Priority 1]
- The current configuration is the result of a cascade of
author-specified user interface information (e.g., "accesskey"
or "tabindex" in HTML), browser defaults,
and user-modified settings.
- 11.3 Allow the user to
control the input configuration for
standard input devices, including the
keyboard, graphical user interface, voice commands, etc.
"One stroke" access
should be possible, for example a single key stroke, voice command, or
button to activate an important functionality.
[Priority 2]
- 11.4 Use system conventions
to provide information to the
user about the current
input configuration for the keyboard, graphical user interface,
voice commands, etc. [Priority 2]
- For example, on some platforms, if a functionality is available from a
menu, the letter of the key that will activate that
functionality is underlined.
- 11.5 Avoid default keyboard,
graphical user interface, voice, or other input configurations
that interfere with or deviate from system conventions. [Priority 2]
- For example, the default configuration should not
include "Alt-F4" or "Control-Alt-Delete" on systems where that
combination has special meaning to the operating system. In particular,
default configurations should not interfere with the mobility access
keyboard modifiers reserved for the operating system. Refer also to guideline
6.
- 11.6 Allow the user to configure the user agent in named profiles that may be shared (by other users or software). [Priority 2]
-
Users must be able to select from among available
profiles or no profile (i.e., the user agent
default settings).
- 11.7 Provide default
keyboard, graphical user interface, voice, and other
input configurations for frequently performed
operations. [Priority 3]
- 11.8 Allow the user to configure the graphical arrangement of user interface controls. [Priority 3]
Glossary
- Input configuration
-
This refers to the mapping between user agent functionality
and activation method. This includes mapping to keyboard
shortcuts, to buttons, to voice commands, etc. Input configurations
should help users remember which functionalities are available
and should allow them to access those functionalities quickly,
and for any supported input or output device.
- Standard Input and Output Devices
- The devices users are expected to use with the operating
system and its standard user interface.
Operating systems provide standard APIs to these devices to be
used by applications.
Ian Jacobs
Last modified: $Date: 2000/11/08 07:48:45 $