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 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.@@
Guideline 4.1 Ensure Full keyboard access
Rationale: tbd MH
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).
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.
The last sentence was added since 03 Jul.
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.
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.
Where would it be documented? Do we need to specify that?
no change
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).
no change
4.1.5 User Agent Keyboard Commands: Direct keyboard commands for the user interface (excluding those derived from the content being rendered) are available:
none. Some concepts were in original 4.1.5.
4.1.X Content Derived Keyboard Commands: Direct keyboard commands that are *recognized* within the content are available:
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
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
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.
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.
no change
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").
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. ")
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.
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
"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
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.).
no change
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.
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.
"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.
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
no change
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.
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.
grammar fix for clarity