Discussion of PFWG Keyboard Access Requirements

Pertinent Parts of UAAG 2.0

source: User Agent Accessibility Guidelines (UAAG) 2.0 (W3C Editors' Draft 23 August 2010)

PRINCIPLE 4. Ensure that the user interface is operable

Guideline 4.1 Ensure full keyboard access

4.1.2 Keystroke Precedence: The user has the option to specify that keystrokes be 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.). (Level A)

• Intent of Success Criterion 4.1.2:
  • There are many layers of software that can specify what happens when the user presses a key. For example, the operating system, the user agent interface, the addons or extensions, and author supplied accesskeys or javascript. In addition, the assistive technology the user may be employing will also have assigned key commands. This results in conflicts in order of operations. These conflicts impact user expectations of what will happen when a key is pressed, causing confusion and failure. The most problematic situation is when the author supplied scripting has precedence on the keyboard commands. Therefore, the user needs a preference that a default order: Operating system, user agent interface, addon/extension, accesskeys, javascript.
• Examples of Success Criterion 4.1.2:
  • The author codes a script that makes bananas dance on the screen when the user presses Alt-F. The user expectation is that Alt-F will open a file menu. When the bananas dance instead of opening the file menu, the user is confused or blocked from opening the file menu and has no recourse. Therefore, the user agent provides a preference setting that makes the Alt-F open the file menu. There needs to be a toggle ability, so that the user who wants to make the bananas dance can do so.
• Related Resources for Success Criterion 4.1.2: To be written

4.1.3 No Keyboard Trap (Minimum): The user agent prevents keyboard traps as follows (Level A):

• (a) in the UI: if keyboard focus can be moved to a component using the keyboard, then focus can be moved away from that component using standard sequential keyboard commands (e.g., TAB key)
• (b) in the rendered content: provides a documented direct keyboard command that will always restore keyboard focus to a known location (e.g., the address bar).
• (c) in the rendered content: provides a documented direct keyboard command that will always move keyboard focus to a subsequent focusable element
  • Intent of Success Criterion 4.1.3: If the user can put focus on an element, that they can remove focus and move on to the next element. This is often a problem with embedded objects. The user agent needs to provide a way to always return to the previous or next element in the content, or a known location, such as the address bar. The user agent also needs to be able to take control back from the embedded object, no matter what it is.
  • Examples of Success Criterion 4.1.3:
    • The user can press tab to put focus on an embedded object and can press shift-tab to move focus to the previous object and tab to move focus to the next object.
    • The user has moved the focus to a toolbar extension that does not relinquish control back to the user agent. The user can press Alt-D to move focus to the address bar.
    • The user has moved the focus to an embedded scripted application that was poorly programmed. the user can press alt-N (or any documented key combination) that overrides the scripting and moves the focus to the next element in the content.
  • Related Resources for Success Criterion 4.1.3:
    • Compound documents
    • Other SC in UAAG.

4.1.4 Separate Selection from Activation: The user has the option to have selection separate from activation (e.g., navigating through a set of radio buttons without changing which is the active/selected option). (Level A)

• Intent of Success Criterion 4.1.4: This is a repair function for when an author violates WCAG, but the user still needs to be able to read a page without necessarily activating any controls.
• Examples of Success Criterion 4.1.4:
  • when a user opens a drop down menu from the keyboard, they must be able to use the arrow keys to move up and down the list, without triggering an action from the items they are moving past.
  • A list of radio buttons where putting the focus on the radio button to read it causes the radio button to be selected. The user should be able to arrow or tab through the list of radio buttons without causing any one to be selected. Selection is a separate discrete operation like spacebar. This overrides any author provided scripting behavior.
• Related Resources for Success Criterion 4.1.4:
  • ARIA 1.0
  • WCAG 2.0

4.1.5 Standard Text Area Navigation Conventions: Views that render text support the standard text area conventions for the operating environment, 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. (Level A)

• Intent of Success Criterion 4.1.5: Providing a full set of keyboard inputs allows users to efficiently--or at all--perform necessary tasks. Making these inputs consistent within and across programs greatly reduces learning curve, cognitive load, and errors.
• Examples of Success Criterion 4.1.5:
  • Directional keys, letter keys, and the Enter key function should allow navigation within and activation of drop-down menus.
  • Ctrl+C or Command+C should copy selected text to the clipboard, allowing the user to avoid manually retyping, and possibly needing to memorize, large amounts of data.
  • Editor's Note: comment - what happens when things are not consistent. closing dialog boxes are inconsistent ESC or ALT-F4, might be text area keyboard conventions/controls, not just navigation. @@
• Related Resources for Success Criterion 4.1.5: To be written

4.1.6 Present Direct Commands in Rendered Content: The user has the option to have any recognized direct commands (e.g. accesskey) in rendered content be presented with their associated elements (e.g. "[Ctrl+t]" displayed after a link whose accesskey value is "t", or an audio browser reading the value or label of a form control followed by "accesskey control plus t"). (Level A)

• Intent of Success Criterion 4.1.6: Make it easy to for users to discover or be reminded of keyboard shortcuts and similar commands without leaving the context in which they're working. Easy keyboard access is especially important for people who cannot easily use a mouse.
• Examples of Success Criterion 4.1.6:
  • "[Ctrl+t]" displayed after a link whose accesskey value is "t".
  • An audio browser reading the value or label of a form control followed by "accesskey control plus t").
  • Mnemonic letters in menu titles are shown with an underline. Editor's Note: comment - applicable shortcut indicated or otherwise highlighted
• Related Resources for Success Criterion 4.1.6: To be written

4.1.7 Present Direct Commands in User Interface: The user has the option to have any direct commands (e.g. keyboard shortcuts) in the user agent user interface be presented with their associated user interface controls (e.g. "Ctrl+S" displayed on the "Save" menu item and toolbar button). (Level AA)

• Intent of Success Criterion 4.1.7: For many users, including those who use the keyboard or and input method such as speech, the keyboard is often a primary method of user agent control. It is important that direct keyboard commands assigned to user agent functionality be discoverable as the user is exploring the user agent.
• Examples of Success Criterion 4.1.7:
  • The speech input user who sees a button on a toolbar needs to be able to determine that ctrl+p is the keyboard equivalent for activating the print button. If such key assignments are not displayed as part of the user interface by default, a user agent should have an option to alter UI display to include all direct hotkey assignments visually as part of the controls the hotkeys activate.
• Related Resources for Success Criterion 4.1.7: To be written

4.1.8 Keyboard Navigation: The user can use the keyboard to navigate from group to group of focusable items and to traverse forwards and backwards all of the focusable elements within each group. Groups include, but are not limited to, toolbars, panels, and user agent extensions. (Level AA)

• Intent of Success Criterion 4.1.8: Let the user navigate between sections without having to sequentially navigate through everything in every section. Efficient keyboard navigation is especially important for people who cannot easily use a mouse.
• Examples of Success Criterion 4.1.8:
  • Ctrl+Tab moves the focus to the first navigable item in the next frame.
  • The Tab key moves the focus to or away from a group of radio buttons, and then directional keys move between buttons within that group.
• Related Resources for Success Criterion 4.1.8: To be written

4.1.9 Important Command Functions: Important command functions (e.g. related to navigation, display, content, information management, etc.) are available using a single or sequence of keystrokes or key combinations. (Level AA)

• Intent of Success Criterion 4.1.9: Let the user access commonly used functions as efficiently as possible. Efficient keyboard navigation is especially important for people who cannot easily use a mouse.
• Examples of Success Criterion 4.1.9:
  • The user can open a document by pressing Ctrl+O or Command+O.
  • The user can temporarily enlarge the rendered content by pressing Ctrl+Plus, rather than having to invoke a menu, choose a command to display a dialog box, select a tab, etc.
• Related Resources for Success Criterion 4.1.9: Links to 1.1. Comply with applicable specifications and conventions

4.1.10 Override of UI Keyboard Commands: The user can override any keyboard shortcut binding for the user agent user interface except for conventional bindings for the operating environment (e.g., for access to help). The rebinding options must include single-key and key-plus-modifier keys if available in the operating environment. (Level AA)

• Intent of Success Criterion 4.1.10: Users need to be in control of how they interact with the user agent. Assistive technology and physical keyboard input needs mean that certain keyboard combinations are easier for a user to enter.
• Examples of Success Criterion 4.1.10:
  • Ctrl+f may be a command in a screen reader to read the item with focus and this is also typically a user agent find command. The user agent should allow the user to reassign the find command to a non-conflicting key binding. To allow this level of user control, the user agent could provide a list of user interface features and default keyboard assignments with options for the user to assign new key combinations. User keyboard customizations should be saved similar to other user preferences by the user agent.
  • editorial note another example - one handed keyboardist needs to map all keys to the left side of the keyboard
• Related Resources for Success Criterion 4.1.10: To be written

4.1.11 User Override of Accesskeys: The user can override any recognized author supplied content keybinding (i.e. access key). The user must have an option to save the override of user interface keyboard shortcuts so that the rebinding persists beyond the current session. (Level AA)

• Intent of Success Criterion 4.1.11:
  • Content authors may utilize the Accesskey attribute to define short cut keys which allow quick access to specific elements, actions, or parts of their Web content. The author-selected short cuts may utilize keystrokes that are unique to their site, differing from conventions used, and or familiar, to users of other similar sites, or sites offering similar functionality. Users of assistive technologies who rely upon keyboard input may wish to have a consistent mapping of shortcut keys to similar, or common actions or functions across the sites they visit.
  • User agents should allow users to define a preferred key combination for specific instances of author defined accesskeys. The user should have the option to make any defined override to be persistent across browsing sessions.
  • User agents may also offer the user the option to automatically apply preferred key combinations for content which has author supplied accesskey bindings, based upon the associated text, label, or ARIA role, and which override any author specified keybinding for that page content.
• Examples of Success Criterion 4.1.11:
  • A speech recognition user has defined standard commands to access commonly used parts of a Web site. For example, speaking the the command "site search" will take the user to a Web site's search function. A site author may assign an access key to set focus to the search input field, basing the accesskey on the first letter of the search engine used (e.g., G for Google or B for Bing, rather than the mnemonic S for search). The speech user has specified an override key mapping of S, which is consistent with the keystroke issued by the speech recognizer they are using.
  • A mobile device user, whose primary keyboard interface is their phone's numeric keypad, maps common Web site actions to numeric shortcut keys. For example, the user prefers to have the 1 key to activate a site's "skip to content" function. An author of a site visited daily by this user defines "S" as the accesskey for the skip to content function. The user overrides the author defined accesskey of "S" with "1".
  • Editor's Note: comment - good place to add i18n example, accesskey - o umlaut, but not on local keyboard
• Related Resources for Success Criterion 4.1.11: To be written

4.1.12 Specify preferred keystrokes: The user can override any keyboard shortcut including recognized author supplied shortcuts (e.g accesskeys) and user interface controls, except for conventional bindings for the operating environment (e.g., for access to help). (Level AA)

• Intent of Success Criterion 4.1.12: N/A
  • Examples of Success Criterion 4.1.12: To be written
• Related Resources for Success Criterion 4.1.12: To be written

Guideline 4.2 Provide access to event handlers

4.2.1 List event handlers: The user can, through keyboard input alone, have presented the list of input device event handlers explicitly associated with the element. (Level A)

• Intent of Success Criterion 4.2.1: Users interacting with a web browser may be doing so by voice, keyboard, mouse or another input technology or a combination of any of these. No matter how the user is controlling the user agent, he or she need to know all the input methods assigned to a particular piece of content.
• Examples of Success Criterion 4.2.1: A user may tab to a link that has a flyout menu that appears OnMouseOver. The User agent needs to notify the user of this menu so he or she can know the menu is available. Other success criteria ensure the keyboard user here can interact with this menu.
• Related Resources for Success Criterion 4.2.1: To be written

4.2.2 Activate any event handler: The user can, through keyboard input alone, activate any input device event handlers explicitly associated with the element. (Level A)

• Intent of Success Criterion 4.2.2: Although it should not do so, some Web content is designed to work only with certain input devices, such as a mouse, and make functionality available only through event handlers for those devices. Some users interacting with a web browser may be doing so by voice, keyboard, mouse or another input technology or a combination of any of these. No matter how the user is controlling the user agent, he or she must be able to activate any of the event handlers regardless of the interaction technology being used.
• Examples of Success Criterion 4.2.2: A user who cannot use a mouse needs to activate a flyout menu that normally appears OnMouseOver. The user should be able to navigate to a link and activate it using keyboard shortcuts.
• Related Resources for Success Criterion 4.2.2: To be written

4.2.3 Activate all event handlers: The user can, through keyboard input alone, simultaneously activate all input device event handlers explicitly associated with the element. (Level A)

• Intent of Success Criterion 4.2.3: One input method should not hold back another. People who don't use a mouse shouldn't necessarily have to map their input methods to the same steps a mouse user would take.
• Examples of Success Criterion 4.2.3:
  • Speech input users may combine moving the mouse up, left and clicking in a single command phrase.
  • A link has an onmousedown and an onmouseup event link. The keyboard user can use 1 key click to activate both events.
• Related Resources for Success Criterion 4.2.3: To be written

Guideline 4.5 Configure and store preference settings.

Intent of Success Criterion 4.5: Users who rely on accessibility settings do so for multiple reasons and may want to adjust software settings in many differing fashions. It is key to allow software settings that impact accessibility to be configured to meet these differing needs. The easier such settings are to discover, the more rapidly the user looking for such settings can tailor the software to suit his or her needs. Saving such configuration changes between browsing sessions allows the software to work the way the user wants each time the application is used.

• Examples of Success Criterion 4.5:
  • A user who relies on larger text sizes when browsing web pages, locates a text adjustment setting in a browser's menus. The user sets the text size to the size that makes web content readable. .
  • A user locates a control in a web browser called options. Activating this control leads to a series of tabs for adjusting multiple browser settings. One tab is listed as accessibility and has settings such as text size, use custom style sheet, display alternative text in place of images, enable caret browsing and other settings determined to be of benefit to users with disabilities.
  • A user is exploring settings for a web browser and locates an option called accessibility. The user is then guided through a series of questions asking about how he or she prefers to use software. Questions such as color preference, text size, ability to view images, the need for captions on videos and such are asked. When the user completes these questions, appropriate browser options are configured and stored.
  • A user who has configured accessibility settings in a browser needs to use that application in the same browser on another computer. The browser allows the user to transfer such settings from one computer to another, saving the need to reconfigure the second machine.

4.5.1 Change Preference Settings: The user has the option to change settings that impact accessibility. (Level A)

4.5.2 Persistent Accessibility Settings: User agent accessibility preference settings persist between sessions. (Level A)

4.5.3 Multiple Sets of Preference Settings: The user can save and retrieve multiple sets of user agent preference settings. (Level AA)

4.5.4 Portable Preference Settings: The user can transfer preference settings across locations onto a compatible system. (Level AAA)

4.5.5 Preferences Wizard: A wizard helps the user to configure (at least) the accessibility-related user agent preferences. (Level AAA)

4.5.6 Restore all to default. The user can restore all preference settings to their default values. (Level A)

4.5.7 Restore related preferences to default. The user can restore groups of related preference settings to their default values (e.g. reset keyboard shortcuts, reset colors and sizes of rendered content, etc.). (Level AA)

4.5.8 Change preference setting outside the UI: The user can adjust preference settings from outside the user agent user interface. (Level AA)

Guideline 4.7 Provide structured navigation.

4.7.1 Structured Navigation: Forward and backward sequential navigation over important (structural) elements in rendered content is provided. (Level A)

• Intent of Success Criterion 4.7.1: Let the user use the keyboard to navigate forwards and backwards through elements that they are likely to be interested in interacting with. These elements must include, but are not limited to, enabled links and controls. This allows the user to jump between elements without having to navigate through intervening content such as blocks of text. Efficient keyboard navigation is especially important for people who cannot easily use a mouse.
• Examples of Success Criterion 4.7.1: The user can press the Tab key to move the focus to the next link or control in the page, or press Shift+Tab to move in the reverse order.
• Related Resources for Success Criterion 4.7.1: See 4.1.4 for discussion of letting the user configure the list of important elements to suit their task.

4.7.2 Direct navigation: direct movement to important (structural and operable) elements in rendered content is provided. (Level A).

• Intent of Success Criterion 4.7.2: Not yet drafted
• Examples of Success Criterion 4.7.2: To be written
• Related Resources for Success Criterion 4.7.2: To be written

4.7.3 Access Relationships: Provide access to explicitly-defined relationships based on the user's position in content (e.g., show form control's label, show label's form control, show a cell's table headers, etc.). (Level A)

• Intent of Success Criterion 4.7.3: postponed for more information about the intent of this SC. Is it about providing flyover information? Or is it out of place and really belongs in [Principle 2]?
• Examples of Success Criterion 4.7.3: To be written
• Related Resources for Success Criterion 4.7.3:
  • also see [ Success Criteria 4.7.x Location in Hierarchy]

4.7.4 Location in Hierarchy: The user can view the path of nodes leading from the root of any content hierarchy in which the structure and semantics are implied by presentation, as opposed to an explicit logical structure with defined semantics (such as the HTML5 Canvas Element), or as a consequence of decentralized-extensibility (such as the HTML5 item / itemprop microdata elements), and only if the user agent keeps an internal model of the hierarchy which it does not expose via the DOM or some other accessibility mechanism. (Level A).

• Intent of Success Criterion 4.7.4: Knowing where you are in a hierarchy makes it easier to understand and navigate information. Users who are perceiving the data linearly (such as audio speech synthesis) do not receive visual cues of the hierarchical information. Efficient navigation of hierarchical information reduces keystrokes for people for whom keypress is time-consuming, tiring, or painful. For people with some cognitive disabilities, providing the clear hierarchy reduces cognitive effort and provides organization.
• Examples of Success Criterion 4.7.4: A media player provides a hierarchical display of playlists, albums, artists and songs, etc. When the user selects an individual item, a breadcrumb of the categories is displayed, can be navigated and is available programmatically.
• Related Resources for Success Criterion 4.7.4: To be written

4.7.5 Direct activation: direct movement to and activation of any operable elements in rendered content is provided. (Level AA)

• Intent of Success Criterion 4.7.5: Not yet drafted
• Examples of Success Criterion 4.7.5: To be written
• Related Resources for Success Criterion 4.7.5: To be written

4.7.6 Configure Set of Important Elements: The user has the option to configure the set of important elements for structured navigation, including by element type (e.g., headers, list items, images). (Level AAA)

• Intent of Success Criterion 4.7.6: Not yet drafted
• Examples of Success Criterion 4.7.6: To be written
• Related Resources for Success Criterion 4.7.6: To be written

4.7.7 Discover navigation and activation keystrokes: Direct navigation and activation keystrokes are discoverable both programmatically and via perceivable labels. (Level A)

• Intent of Success Criterion 4.7.7: Not yet drafted
• Examples of Success Criterion 4.7.7: To be written
• Related Resources for Success Criterion 4.7.7: To be written

---

Feedback on PFWG Keyboard Access Requirements

Feedback From UAWG Members

Feedback from Jan Richards

source: post to w3c-wai-ua@w3.org (2010-08-26)

• Sighted keyboard-only users would benefit from the ability to see an overlay of the available access keys on the UI.
• Requirement 4 and Requirement 9 seem to be pointing at the need to get a global view of available access key with descriptions (if provided)...if descriptions aren’t provided (as they often won’t be I expect), maybe descriptions could be built from the semantics of the elements pointed to.
• One thing that always concerns me about access key is when authors put accesskeys into prose – as in help files (this would get thrown off by a cascade or user over-rides). One possibility would be to give the author the ability to put in placeholders into their prose that points to an ID...and then that placeholder would get the calculated access key value (like dynamic figure references in Word processors).

Feedback from Kim Patch

source: post to w3c-wai-ua@w3.org (2010-09-23)

I think there's one critical omission -- direct navigation.

Sequential navigation works well when the user is cycling through only a few elements. Requirements 5-9 cover this well. Sequential navigation worked well for jumping among web pages when there are only a few links on a page. This was the case in the early days of the web, but many of today's web pages have tens or hundreds of elements including links, rendering sequential navigation tedious at best and unusable at worst.

The mouse gives users a good way to go directly to any element, sidestepping the issue for many users. But users who find it difficult or impossible to use the mouse cannot be expected to rely on sequential navigation for everything they do on the web. This can slow navigation by order of magnitude or more.

Direct navigation by keyboard to all the elements covered by sequential navigation is critical to make the web usable for those who cannot use a mouse. There's a good implementation example in Firefox: the Mouseless Browsing extension (https://addons.mozilla.org/en-US/firefox/addon/879/)

UAAG addresses this in 4.7.2, and 4.7.5, but the intent and examples have not yet been drafted.

4.7.2 Direct navigation: direct movement to important (structural and operable) elements in rendered content is provided. (Level A).
4.7.5 Direct activation: direct movement to and activation of any operable elements in rendered content is provided. (Level AA)

Requirement 2 would enable users in a more powerful way if the default access mapping and user override mapping could be stored and shared.

Requirement 4 would enable users in a more powerful way if:

• the user overrides could also be described
• the descriptions could be stored and shared along with the mappings

Feedback from Greg Lowney

• source: Greg Lowney post to w3c-wai-ua (2010-09-24), in reply to a post by Bim Egan

... accesskey was originally put in specifically so it would use the same modifier key as the browser UI. At least as it was discussed within Microsoft, the goal was to allow HTML authoring of forms, dialog boxes, and other user interfaces have the platform's "look and feel" so the user wouldn't have to know or care whether UI was written using HTML or the native Windows API, VB, etc. Since Windows menus and dialog box controls used the Alt-key modifier, so did accesskey.

Of course a browser can use a different modifier key for accesskey (or its equivalent) than for its built-in UI, but that would make HTML-authored dialog boxes and forms extremely confusing for users. Imagine if a dialog box comes up and you have to guess which modifier key to press to activate its controls, because you don't know whether it's native or author-defined...

Luckily, the Windows UI (based on IBM's CUA standard) included a mechanism for handling conflicts: if more than one element in the active context shared the same underlined access key, pressing that key or key combination would move the focus to the next element with that access key, but not automatically activate it, leaving the user to either navigate away (by repeating the access key or other means) or press a key to activate the element. Thus, at least in native applications, you could still do everything in a way that was pretty much optimal given the conflict, but the UI did change enough that it could confuse users who weren't used to this convention or to accesskeys suddenly changing behavior.

---

Discussion Threads on w3c-wai-ua

• Accesskey Discussion (Simon Harper)
  • "I seems to me that HTML5 is becoming increasingly platform like. In this case I suggest that HTML5 specify a number of predefined accesskeys for common functionality including those useful for WebApps."
• Re: Accesskey Discussion (Bim Egan)
  • "Sorry to butt in here, but it concerns me that as accesskey bindings frequently conflict with keyboard access to browser toolbars or plug-ins, and can also change settings in access technology that runs in the background while being sensitive to all keystrokes, such as screen readers, defined accesskeys could result in all HTML5 pages using them being inaccessible to people who navigate via keyboard or use access tech software, instead of the current situation where it is difficult only on some sites using code that conforms to specification."
• Re: Accesskey Discussion (Charles McCathieNevile)
  • "Actually, the problem is stupid browser implementation binding author-assigned accesskeys to something that normally has a different function. There is also a problem of authors using javascript to trap the keyboard,which has the same effect."
  • quoting Bim Egan's suggestion: "that HTML5 specify a number of predefined accesskeys for common functionality including those useful for WebApps." Charles replied: "No, that is what rel attributes are for. That allows browsers to define whatever activation they want, that will be common across sites, and won't interfere with the existing browser UI."
• Re: Accesskey Discussion (Greg Lowney)
  • "User needs to be able to to assign priorities of various keyboard shortcuts, e.g. when user, user agent, and content all try to assign the same key to different functions. Browsers need to mediate, but the user needs final say."
  • "When there is a conflict between keyboard commands defined by content, user, and user agent, all of the commands still *need to be available* even if the user's preferences end with some being overridden. For example, if two things want to be Ctrl+S, one would be changed to another modifier, or a menu provides access to the various commands without using their keyboard shortcuts."
  • "As documentation often refers to the keyboard commands originally specified by the content author or UA developer, the user may want to be able to determine the actual keyboard commands used on their system as it's currently configured (e.g. overridden keys, or change of modifier imposed by the user agent). For example, if a help topic tells them to press Command+S but they're running on a system without a Command key, they can determine that their browser changed it to Ctrl+S. Or if a Web page assigns Alt+F as a shortcut key to a form field, but the user remaps it to Ctrl+Shift+F to avoid conflicting with the keyboard command for their browser's File menu (or their assistive technology), they can look up to see what Alt+F was remapped to."
  • "Ideally the user agent should also be able to provide the user with information as to what a keyboard command does, or at least which component (e.g. which html document, script, style sheet, plug-in, etc.) is handling it. For example, if they press a key combination expecting one behavior and something mysterious happens instead, they can examine a list of active keyboard commands to find that the current Web page has assigned that key combination to activate a particular form control, or that a particular plug-in is consuming it, etc."
• Re: Accesskey Discussion (Simon Harper)
  • in reply to Bim's post: "this is really just a problem of the browser not implementing the bindings in rationale way. Indeed, a modifier key would easy sort this out."
• Re: Accesskey Discussion (Greg Lowney)]
  • quoted above at length

• proposed HTML keyboard requirements based on UAAG 2.0 GL 4.2 "Provide access to event handlers" (Gregory J. Rosmaita)
• REQUIREMENT EV1: a user must, through keyboard input alone, have the ability to obtain the list of input device event handlers explicitly associated with an element.
  • Explanatory note EV1.1: Users interacting with a web browser may be doing so by voice, keyboard, mouse or another input technology or a combination of any of these. No matter how the user is controlling the user agent, he or she need to know all the input methods assigned to a particular piece of content.
  • Explanatory note EV1.2: this is a Level A requirement of UAAG 2.0 SC 4.2.1. "List Event Handlers"
• REQUIREMENT EV2: a user must, through keyboard input alone, be able to activate any input device event handlers explicitly associated with an element.
  • Explanatory note EV2.1: Although it should not be so designed, some Web content is designed to work only with certain input devices, such as a mouse, thereby limiting the availability of those event handlers to specific devices. Some users interacting with a web browser may be doing so by voice, keyboard, mouse or another input technology or a combination of any of these. No matter how the user is controlling the user agent, he or she must be able to activate any of the event handlers regardless of the interaction technology being used.
  • Explanatory note EV2.2: A user who cannot use a mouse needs to activate a flyout menu that normally appears OnMouseOver. The user should be able to navigate to a link and activate it using keyboard shortcuts.
  • Explanatory note EV2.3: This is a UAAG 2.0 SC 4.2.2 "Activate any event handler", a Level A requirement
• REQUIREMENT EV3: a user must, through keyboard input alone, be able to simultaneously activate all input device event handlers explicitly associated with an element.
  • Explanatory note EV3.1: One input method should not hold back another. People who don't use a mouse shouldn't necessarily have to map their input methods to the same steps a mouse user would take.
    • Examples:
      • Speech input users may combine moving the mouse up, left and clicking in a single command phrase.
      • A link has an onmousedown and an onmouseup event link. The keyboard user should be able to use 1 key click to activate both events.
  • Explanatory note EV3.2: this is UAAG 2.0 SC 4.2.3 "Activate all event handlers" a Level A requirement

---