W3C logoWeb Accessibility Initiative (WAI)         logo

Guideline 4.1 Keyboard

This is my overview of all the different keyboard proposals compared to the existing text as of the 12 March 2008 Public Working Draft. It is confusing to track what is Existing, Proposed, or Notes for reference. I have made some visual formatting to help clarify this for those who don't have navigation by heading. Each guideline is treated separately, with sections for Existing, Proposed, and Notes, if applicable.

Note: Anything marked with @@ text @@ is the editor's notation from the UAAG 2.0 Public Working Draft. I have removed many of them to improve clarity.

 

Guideline 4.1

Existing

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.@@

Proposed from Jeanne

Guideline 4.1 Ensure Full keyboard access

Rationale: tbd MH

Guideline 4.1.1

Existing

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).

Proposed from Jeanne

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). This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

Jeanne Notes:

The last sentence was added since 03 Jul.

Jim's Notes on proposal for 4.1.1

  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

Guideline 4.1.2

Existing

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.

Proposed from Jeanne

4.1.2 Documentation of 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 co-located with the list of Keyboard Commands.

Notes from Jeanne on the proposal for 4.1.2

Where would it be documented? Do we need to specify that?

Guideline 4.1.3

Existing

Proposed

no change

Guideline 4.1.4

Existing

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).

Proposed

no change

Guideline 4.1.5

Existing

Proposed

New Proposal of Jul 9 from Jan & Jeanne

4.1.5 User Agent Keyboard Commands: Direct keyboard commands for the user interface (excluding those derived from the content being rendered) are available:

Guideline 4.1.x

Existing

none. Some concepts were in original 4.1.5.

Proposed by Jan & Jeanne

4.1.X Content Derived Keyboard Commands: Direct keyboard commands that are *recognized* within the content are available:

Text of Proposals #3,4,5 and 6 for Reference Purposes:

#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

Guideline 4.1.6

Existing

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.

Proposed

no change

Guideline 4.1.7

Existing

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").

Proposed from Jeanne

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, and user agent extensions using the conventions of the platform (e.g., via "tab", "shift-tab", etc. ")

Guideline 4.1.8

Existing

Level AA Success Criteria for Guideline 4.1

Proposed from Jeanne

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

Notes on Proposals for Reference

#2 Proposal from Jim: 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 from Jim: 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 indicate

 

Guideline 4.1.9

Existing

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.).

Proposed

no change

Guideline 4.1.10

Existing

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.

Proposed from Jeanne

4.1.10 User Override of Keyboard Commands: The user can override any keyboard shortcut 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 user can override any author supplied content keybinding (i.e. access key) that the user agent can recognize. The keyboard combinations offered for rebinding include single key and key plus modifier keys if these are available in the operating environment. The user must have an option to save the override of user interface keyboard shortcuts so that the rebinding persists beyond the current session.

Notes from Jeanne on proposed 4.1.10

"Binding" is a confusing term that that needed additional clarification.

I thought we also needed something here to address the persistence of binding. I would like to add a new AAA guideline that allows users to import and export custom keyboard mapping.

Original notes from Jim on proposed 4.1.10 for reference purpose:

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 user can override any author supplied content keybinding (i.e. access key) that the user agent can *recognize*. The keyboard combinations offered for rebinding include single key and key plus modifier keys if these are available in the operating environment.

Note: *recognize* is a defined term. With AJAX and other scripting authors can create keybindings of which the UA is unaware and has no ability to allow the user to reassign keybindings. See SC 4.1.5
Recognize - http://www.w3.org/TR/2008/WD-UAAG20-20080312/#def-recognize

Guideline 4.1.11

Existing

Level AAA Success Criteria for Guideline 4.1

Proposed

no change

Guideline 4.1.12

Existing

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.

Proposed from Jeanne

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 controls in the current group.

Notes from Jeanne on proposed 4.1.12

grammar fix for clarity