Proposals for Guideline 4.1 Keyboard

Guideline 4.1 Ensure full keyboard access [Techniques]

@@The UAWG is currently working to ensure that sufficient requirements are in place regarding how keyboard shortcuts are conveyed to the user (e.g. visual indicators, documentation, etc.). Input from area experts would be welcome.@@

@@The UAWG is also currently working to ensure that the requirements properly cover interaction with video and dynamic Web content. Input from area experts would be welcome.@@

Level A Success Criteria for Guideline 4.1

• 4.1.1 Keyboard: The user can, through keyboard input alone, navigate to and operate all of the functions included in the user interface (e.g., navigating and selecting content within views, operating the user interface "chrome", installing and configuring the user agent, and accessing documentation), except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g. freeform drawing). This applies to at least one mechanism per "browsing outcome"@@DEFINE@@, allowing non-keyboard accessible mechanisms to remain available (e.g., providing resizing with mouse-"handles" and with keystrokes).@@1.1 in UAAG10@@[ATAG 2.0]

4.1.1 Keyboard Operation: All functionality can be operated via the keyboard using sequential and/or direct keyboard commands that do not require specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g., free hand drawing).

Notes for proposal:

1. Might be more clear if we could define "free hand drawing" with some of the ideas in the current discussion would help make clear why an exception is needed.
2. The bit about *sequential* and *direct* is needed in UAAG but not WCAG 2.0 because the two guidelines handle keyboard control of the mouse differently (i.e. WCAG conformance does not cover AT's, but UAAG conformance can).

Jim's proposal for redefining the terms is at: http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0004.html

• 4.1.2 Precedence of Keystroke Processing: The precedence of keystroke processing between the user agent interface, user agent extensions, content keystroke operations administered by the user agent (e.g., access keys), and executable content (e.g., key press events in scripts, etc.) is documented.@@NEW@@

• 4.1.3 No Keyboard Trap: If focus can be moved to a component with the keyboard, then at least one of the following is true: @@WCAG2 concept@@
  • (a) standard keys: focus can be moved away from the component with the keyboard using standard navigation keys (i.e., unmodified arrow or tab keys), or
  • (b) documented non-standard keys: focus can be moved away from the component with non-standard keys and the user is advised of the method.

• 4.1.4 Separate Activation: The user has the option to have selection separate from activation (e.g., navigating through the items in a dropdown menu without activating any of the items).@@9.5 in UAAG10@@[ATAG 2.0]

• 4.1.5 Available Keystrokes: The user can always determine available binding information in a centralized fashion (e.g., a list of bindings) or a distributed fashion (e.g., by keyboard shortcuts listed in user interface menus) for the following: @@11.1,11.2 in UAAG10@@
  • (a) user interface "chrome" and extensions (including any user re-mappings), and
  • (b) content keybindings that the user agent can recognize.

Jeanne proposal (new)

4.1.5 Available Keyboard Shortcuts: The user can always determine available keyboard shortcuts by both:

• (a) A user setting in which any recognized keyboard shortcut for currently visible content is visually displayed (e.g. an underlined letter or inclusion in a user interface menu).
• (b) A list of all keyboard shortcuts that is prominent in the documentation.

Proposal #5: "Separate lists are permitted for the "base" user agent, each extension, and each plug-in." How could that work? How would the user find the keyshortcuts for a browser plug-in if it isn't in the Help menu?

Does Proposal #4 (If a keyboard shortcut exists for a component, then it is available programmatically. ) also belong here? What is the reason to have it available programmatically? for AT?

#3 Proposal:Visual Keyboard Shortcut Indicator (Content Display):

Provide a user setting in which any recognized keyboard shortcuts for currently visible content are visually indicated (e.g., with overlays). Jim: what is an 'overlay'? JR: I was thinking about something the User Agent draws that hovers over the rendered page. The reason for this is that in HTML accesskeys are independent of any text label...so you can't just render an underline under a letter in the label (in fact there may be no label). From: http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0058.html

#4 Proposal: Programmatically Available Keyboard Shortcuts ("Chrome" and Content Display):

If a keyboard shortcut exists for a component, then it is available programmatically.

No previous discussion. From: http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0058.html

#5 Proposal: Document Keyboard Shortcuts ("Chrome")

Document Keyboard Shortcuts ("Chrome"): Any *direct keyboard commands* are listed in the documentation. Note: Separate lists are permitted for the "base" user agent, each extension, and each plug-in.

#6 Proposal:Content Focus Keyboard Commands (Content Display):

Users may request a list of all keyboard commands that are currently available and are "recognized" to move the content focus.

• 4.1.6 Standard Text Area Conventions: Views that render text support the standard text area conventions for the platform including, but not necessarily limited to: character keys, backspace/delete, insert, "arrow" key navigation (e.g., "caret" browsing), page up/page down, navigate to start/end, navigate by paragraph, shift-to-select mechanism, etc. @@7.1 in UAAG10@@ [ATAG 2.0]

• 4.1.7 "Chrome" Navigation: The user can use the keyboard to traverse all of the controls forwards and backwards, including controls in floating toolbars, panels, user agent extensions @@DEFINE@@, etc. using conventions of the platform (e.g., via "tab", "shift-tab", "ctrl-tab", "ctrl-shift-tab").[ATAG 2.0]

Jeanne proposal (new)

4.1.7 User Interface Navigation: The user can use the keyboard to traverse all of the controls forwards and backwards, including controls in floating toolbars, panels, user agent extensions @@DEFINE@@, etc. using conventions of the platform (e.g., via "tab", "shift-tab", "ctrl-tab", "ctrl-shift-tab").[ATAG 2.0]

Level AA Success Criteria for Guideline 4.1

• 4.1.8 Accelerator Keys: If any of the following functionalities are implemented by the user agent, the user has the option to enable key-plus-modifier-key (or single-key) access to them:@@11.5 in UAAG10@@ [ATAG 2.0]
  • (a) move content focus to the next/previous enabled element in document order,
  • (b) activate the link designated by the content focus,
  • (c) open search function, search again
  • (d) increase/decrease the scale of rendered text,
  • (e) increase/decrease global volume,
  • (f) stop/pause/resume and navigate efficiently audio and animations, including video and animated images,
  • (g) next/previous history state (i.e., forward/back),
  • (h) enter a URI for a new resource,
  • (i) add a URI to favorites (i.e., bookmarked resources),
  • (j) view favorites,
  • (k) reload a resource,
  • (l) interrupt a request to load or reload a resource,
  • (m) for graphical viewports@@DEFINE?@@: navigate forward and backward through rendered content by approximately the height of the viewport, and
  • (n) for user agents @@Line based user agents? DEFINE@@ that render content in lines of (at least) text: move the point of regard to the next and previous line.

Jeanne proposal (new)

4.1.8 Ensure Keyboard Shortcuts: Any user interface component that can receive focus has a keyboard shortcut unless the operating environment prevents this. Currently visible user interface components visually indicate their keyboard shortcuts.

#2 Proposal: Ensure Keyboard Shortcuts:

Any user interface "chrome" component that can receive *user interface focus* using the keyboard has a keyboard shortcut, unless the *operating environment* prevents this.

Jim: I like this. This provides for quick access to menu items. So, if I need to open an email archive, I can hit 'ALT+F, A' rather than 'ALT+F and multiple down arrows. I think we still need something about common actions that have shortcut keys but are 2 submenu levels down (sort of like deep linking to a menu command). For example, in Firefox changing text sizes is one submenu off of the 'view' menu, but 'increase' and 'decrease' font size each have a shortcut key combination (CTRL+ and CTRL-). My concern is that 'common actions' is hard to define and may be too prescriptive.).

JR: 4.1.8 is where we would put "common" things requiring accelerator keys. I meant for (2) to apply to currently visible things in each state of the system...not that there be ctrl+ combinations for everything at every level. I also see (2) as a lower priority.

From http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0058.html

#1 Proposal: Visual Keyboard Shortcut Indicator ("Chrome")

"Chrome" is used to mean the application user interface. Separate from content user interface. This proposal was slightly edited to include nits and clarifications from the included discussion below.

(1) Visual Keyboard Shortcut Indicator ("Chrome") Provide a user setting in which currently visible user interface "chrome" components visually indicate their keyboard shortcuts, IF ANY (e.g., with access key letters underlined).

Previous discussion. Jim: example should also include modifier key plus letter for items in a menu. My wording could use some work. I am trying to include not just the top level user interface items (accesskey underlined) but the items in the menus (Save Ctrl+S). Also have a concern about 'accesskey'. It may be confused with the HTML @accesskey. Suggest 'shortcut key' in place of 'accesskey' Nit: 'indicated' should be 'indicate' JR: I should have said "Access key" which is the proper term (http://www.usabilityfirst.com/glossary/term_526.txl), which we should define. I purposefully left out modifier+key (e.g. Ctrl+S) because if the File menu is closed how will this be indicated

• 4.1.9 Precedence of Keystroke Processing: Keystrokes are processed in the following order: user agent user interface, user agent extensions, content keystroke operations administered by the user agent (e.g., access keys), and executable content (e.g., key press events in scripts, etc.).@@NEW@@

• 4.1.10 User Override any Binding: The user can override any binding that is part of the user agent default input configuration except for conventional bindings for the operating environment (e.g., for access to help). The keyboard combinations offered for rebinding include single key and key plus modifier keys if these are available in the operating environment. @@11.3,11.4 in UAAG10@@

Level AAA Success Criteria for Guideline 4.1

• 4.1.11 Intergroup Navigation: If logical groups of focusable controls (e.g., toolbars, dialogs, labeled groups, panels) are present, the user can use the keyboard to navigate to a focusable control in the next and previous groups.[ATAG 2.0] @@NEW@@

• 4.1.12 Group Navigation: If logical groups of focusable controls are present, the user can use the keyboard to navigate to the first, last, next and previous focusable controls in the current group.[ATAG 2.0]@@NEW@@