Comments on Guidelines 1 and 2 of User Agent Accessibility Guidelines 1.0

Reference document:
http://www.w3.org/WAI/UA/WAI-USERAGENT-19991005
Editor: Marja Koivunen

4. User Agent Accessibility Guidelines

Guideline 1. Support input and output device-independence

1.1 Ensure that all functionalities offered through the user interface may be operated through standard input device APIs supported by the operating system. [Priority 1]
Techniques for checkpoint 1.1
!!The API requirement already here. No need to have again in 2.!!

Guideline 2. Ensure graceful keyboard access to user agent functionalities

Ensure that the user has access to user agent functionalities by means that transform gracefully to different input devices. Keyboard access is crucial as it does not require pointing and is through the keyboard since keyboard access is widely supported.

!!Some of the examples related to this GL are already in the Guideline 1 text.!!

Ensuring access to user agent functionality through the system's standard keyboard API (where available) is important to accessibility since keyboard access is available to many users and is widely supported. Keyboard access here means direct mapping from keystrokes to UA functions. (Keyboard keys may be used also for emulating pointing and using the gui for mapping to UA functionalities, but that is not enough to provide accessibility.) Even when a user doesn't use a physical keyboard, it is still possible to simulate keyboard events with software. This guideline is important for ensuring compatibility between graphical desktop browsers and dependent user agents.

When using a physical keyboard, some users require single-key access, others require that keys activated in combination be physically close together, while others require that they be spaced physically far apart. When allowing users to configure keyboard access to functionalities, user agents must consider system conventions, author-specified shortcuts, and user preferences. The user agent's default configuration should include shortcuts for frequently performed actions and should respect system conventions.

The more apparent the keyboard commands are to all users, the more likely it is that new users with disabilities will find them and use them. Refer also to checkpoint 9.12.

Checkpoints in this section do not apply to user agents (e.g., kiosks) that do not natively support keyboard input.

!!What does this mean? Provide keyboard access only when you provide it?!!

2.1 By default and without additional customization, ensure that all functionalities offered by the user agent can be activated by dedicated keystrokes may be operated through the standard keyboard API supported by the operating system.

!!The idea is that it must be an unambiguous keystroke, not one that changes according to the cursor position. This prevents mouse emulation to count.!!

[Priority 1]
Note. Functionalities include being able to show, hide, resize and move graphical viewports created by the user agent.
Techniques for checkpoint 2.1

2.1b Ensure that all functionalities offered by the user agent can be activated by pointing through the standard mouse API . [Priority 3]
2.? Provide user memory aids of the available user agent functionalities. E.g. visually in graphical ui, shortcut keys, a key command or a menu window to list all commands (visual, audio, tactile).
!!Related to 2.2. but from functionality viewpoint.!!
2.2 Provide documentation on default keyboard commands and include with user agent documentation and/or user help system. [Priority 1]
Refer also to guideline 12.
Techniques for checkpoint 2.2
2.3 Provide information to the user about the current keyboard configuration. [Priority 1]
Note. For example, users should be able to find information about complex key combinations. Refer also to guideline 12.
Techniques for checkpoint 2.3
!!Information about mapping of the keys to the functions?!!
2.4 Allow the user to configure the keystrokes used to activate user agent functionalities. Users should be able to configure single key activation of functionalities. [Priority 2]
Techniques for checkpoint 2.4
!!Also allow the dependent UA to provide a mapping and change the mapping temporarily so that e.g. a speech command activating a certain function through keyboard API would activate the same function even though the user has configured the keyboard commands differently. Or how does this work?!!
2.5 Allow the user to turn on and off author-specified keyboard configurations. [Priority 2]
For example, in HTML, the author may specify tabbing order with the "tabindex" attribute and keyboard bindings with the "accesskey" attribute.
Techniques for checkpoint 2.5
2.6 Use platform conventions to indicate which keys activate which user agent functionalities. [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.
Techniques for checkpoint 2.6
2.7 Avoid default keyboard configurations that interfere with 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.
Techniques for checkpoint 2.7
2.8 Provide a default keyboard configuration for frequently performed operations. [Priority 3]
Techniques for checkpoint 2.8
2.? Use the same mappings of keys to UA functionalities as the other UAs whenever there are conventions available.