- From: Al Gilman <asgilman@iamdigex.net>
- Date: Thu, 28 Oct 1999 22:53:33 -0500
- To: w3c-wai-ua@w3.org
Ref: http://www.w3.org/WAI/UA/1999/10/g1g2-proposal
Note: I haven't cut this down, skip to AG:: for my comments. Sorry I am
not up to date with discussion since this was posted. You may have got all
these points already.
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
[1]Marja's message of 29 September 1999. See also [2]Marja's comments
on Guidelines 1 and 2 upon which this proposal is founded. It also
takes into account [3]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.
AG:: I believe that that is incorrect in human-computer interaction terms
a.k.a.
human factors. The first or highest requirement is indeed that the user be
able to know and look up what the exact key bindings are right now; but it
is also valuable and important that the user be able to know and remember
which of these are there because of the client program and will be the same
for all pages. Conversely which are ephemeral and cannot be expected to
act the same elsewhere.
* 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: [4]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
2. User Agent Accessibility Guidelines
Guideline 1. Support input and output device-independence
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 [5]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.
AG:: I don't think you have this stated just right just yet.
Supported devices: should be the standard devices for the environment plus
others ad lib.
Device communication: Where there is a standard API for these devices
supported by the environment, this API should be used. In general, if the
OS or language supports a standard mechanism for intercepting the
communication with a device, the communication with that device should pass
through this mechanism so that the device may be emulated by AT through
this mechanism at the user and AT's discretion.
1.2 Ensure that the user can interact with all [6]active elements in a
[7]device independent manner. [Priority 1]
For example, ensure that the user can [8]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 [9]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.
AG:: To me, display is a functionality. I would state this more carefully
as "ensure that all user actions or commands may be exercised through..."
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.
Guideline 11. Allow the user to configure the user agent
11.1 Document the default [10]input configuration for the keyboard,
graphical user interface, voice commands, etc. [Priority 1]
AG:: Document ... in universally-accessible media [WEBCONTENT].
11.2 Provide information to the user about the current [11]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.
AG:: I would say "provide interactive access to..." rather than just "provide
information" only because on first reading the latter could be taken for
paper documents (even 'though it becomes obvious later in the sentence that
this won't work..)
11.3 Allow the user to control the [12]input configuration for
[13]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 [14]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. [15]Refer also to guideline 6.
11.6 Allow the user to [16]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 [17]input configurations for frequently performed
operations. [Priority 3]
11.8 Allow the user to [18]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: 1999/10/26 01:03:59 $
References
1. http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0437.html
2. http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0124.html
3. http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0098.html
4. http://www.w3.org/WAI/UA/WAI-USERAGENT-19991022
5. http://www.w3.org/WAI/UA/1999/10/g1g2-proposal#def-viewport
6. http://www.w3.org/WAI/UA/1999/10/wai-useragent.html#def-active-element
7. http://www.w3.org/WAI/UA/1999/10/wai-useragent.html#def-device-ind
8. http://www.w3.org/WAI/UA/1999/10/g1g2-proposal#def-activate
9. http://www.w3.org/WAI/UA/1999/10/g1g2-proposal#def-stdio
10. http://www.w3.org/WAI/UA/1999/10/def-config-input
11. http://www.w3.org/WAI/UA/1999/10/def-config-input
12. http://www.w3.org/WAI/UA/1999/10/g1g2-proposal#def-config-io
13. http://www.w3.org/WAI/UA/1999/10/g1g2-proposal#def-stdio
14. http://www.w3.org/WAI/UA/1999/10/def-config-input
15. http://www.w3.org/WAI/UA/1999/10/g1g2-proposal#gl-accessible-interface
16. http://www.w3.org/WAI/UA/1999/10/wai-useragent.html#def-configure
17. http://www.w3.org/WAI/UA/1999/10/g1g2-proposal#def-config-input
18. http://www.w3.org/WAI/UA/1999/10/wai-useragent.html#def-configure
Received on Thursday, 28 October 1999 22:49:40 UTC