• InOutDevIndep

1. Support input and output device-independence

1.1 Full keyboard access (P1)

(Original)

1. Ensure that the user can operate, through keyboard input alone, any user agent functionality available through the user interface.

Normative inclusions and exclusions

1. This checkpoint excludes the requirements of checkpoint 1.2.
2. Conformance detail: For both content and user agent

Notes

• For example, ensure that the user can interact with enabled elements, select content, navigate viewports, configure the user agent, access documentation, install the user agent, and operate user interface controls, all entirely through keyboard input.

UAAG2 ISSUES

• Nov.4.JA,JR: "any functionality available throught the user interface" - if content not coded right then ua can't get there
• Nov.4.JR: Maybe we want to work on a concept of "browser understood user interface rendered controls"- if something has tabindex-1 it has been hidden by author and UA no longer has responsbility?

1.2 Activate event handlers (P1)

(Original)

1. Allow the user to activate, through keyboard input alone, all input device event handlers that are explicitly associated with the element designated by the content focus.
2. In order to satisfy provision one of this checkpoint, the user must be able to activate as a group all event handlers of the same input device event type. For example, if there are 10 handlers associated with the onmousedown event type, the user must be able to activate the entire group of 10 through keyboard input alone, and must not be required to activate each handler separately.

Normative inclusions and exclusions

1. Provision one of this checkpoint applies to handlers of any input device event type, including event types for keyboard, pointing device, and voice input.
2. The user agent is not required to allow activation of event handlers associated with a given device (e.g., the pointing device) in any order other than what the device itself allows (e.g., a mouse down event followed by a mouse drag event followed by a mouse up event).
3. The requirements for this checkpoint refer to any explicitly associated input device event handlers associated with an element, independent of the input modalities for which the user agent conforms. For example, suppose that an element has an explicitly associated handler for pointing device events. Even when the user agent only conforms for keyboard input (and does not conform for the pointing device, for example), this checkpoint requires the user agent to allow the user to activate that handler with the keyboard.
4. This checkpoint is mutually exclusive of checkpoint 1.1 since the current checkpoint may be excluded from a conformance profile, unlike other keyboard operation requirements.
5. Conformance profile labels: Events

Notes

• Refer to the checkpoints of guideline 9 for more information about focus requirements.

UAAG2 ISSUES

• Nov.4.JA,JR: Need to clarify once again what's allowed to get focus.
• Should we reference other APIs, such as accessibility APIs??:

  • http://lists.w3.org/Archives/Public/w3c-wai-ua/2006AprJun/0073.html also

  • http://developer.apple.com/documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXModel/chapter_4_section_1.html

ckl: Add some more techniques related to ARIA and accessibility APIs, such as:

12. ckl: In a Rich Internet Application (RIA), an element with an event handler often defines a widget and has a defined "role" attribute to describe the behavior of the widget. The user agent must expose the value of role attributes to assistive technologies through DOM interfaces but should also expose these attributes using platform accessibility APIs. IAccessible2 (IA2) for Windows and the Accessibility Toolkit (ATK) for Linux have roles defined which easily map to roles defined for Accessible Rich Internet Applications (ARIA).

• ckl:See http://www.w3.org/TR/aria-role/ for ARIA roles.

• ckl:See http://accessibility.freestandards.org/a11yspecs/ia2/docs/html/ for IA2 roles.

• ckl:See http://developer.gnome.org/doc/API/2.0/atk/AtkObject.html#AtkRole for ATK roles.

1.3 Provide text messages (P1) Techniques for checkpoint 1.3

(Original)

1. Ensure that every message (e.g., prompt, alert, or notification) that is a non-text element and is part of the user agent user interface has a text equivalent.

2. ckl: Allow configuration not to render non-essential or low priority text messages based on priority properties defined by the author.

Notes

• For example, if the user is alerted of an event by an audio cue, a visually-rendered text equivalent in the status bar could satisfy this checkpoint. Per checkpoint 6.5, a text equivalent for each such message must be available through an API. See also checkpoint 6.6 for requirements for programmatic notification of changes to the user interface.

• ckl: Examples of priority properties for a text message are off (not currently live), polite (low priority), assertive (medium priority), and rude (high priority) for AJAX live regions.

ckl: Under techniques for this guideline, reference Live Regions section of ARIA States spec: http://www.w3.org/TR/aria-state/#liveregions

UAAG2 ISSUES

• Nov.4.JA: "1.3.2 Allow configuration by user to override the priority level of text messages defined by the author."?

• http://www.w3.org/2006/06/15-ua-minutes.html

• allowing non-essential (IF IDENTIFIED) alerts and text messages to be optional (turned off by the user if desired).
• AJAX implications as things change on-screen without a refresh