This was was cloned from bug 13576 as part of operation LATER convergence.
Originally filed: 2011-08-03 05:17:00 +0000
Original reporter: Greg Lowney <gcl-0039@access-research.org>

================================================================================
 #0   Greg Lowney                                     2011-08-03 05:17:46 +0000 
--------------------------------------------------------------------------------
Users who rely solely on the keyboard benefit greatly from having a great number of keyboard commands (accesskeys, hotkeys, etc.) defined by content, add-ins, user settings, etc. Unfortunately the design of the accesskey attribute currently limits each shortcut to a single Unicode code point, to which the user agent may arbitrarily zero or more modifier keys. This severely limits the number of shortcut keys available at one time and restricts the ability of components to assign meaningful and easily remembered keybindings. This is particularly important for web-based applications such as word processors which would want to define a large number of keys, and also for accessibility aids such as browser add-ins that add shortcuts for all operable elements on a page. HTML5 should correct this by allowing components to take advantage of a wider range of keyboard inputs as shortcuts. 

Aspects of this discussed below include: (a) allowing sequences as shortcuts; (b) enabling unmodified keys as shortcuts; and (c) allowing non-character keys as shortcuts; and (d) specifying detailed shortcuts.

A. Allowing sequences as shortcuts

Allowing key sequences to be used as commands greatly increases the number of keyboard commands that can be used, as well as the ability to make these command mnemonic.

    * Use case: Jemiah is a keyboard user who wants to make her work as efficient as possible. She configures her Web-bases word processor to set up shortcut keys for the dozens of the built-in commands and macros she uses frequently, especially those that would normally take many keystrokes to carry out. However, she quickly runs out of good keystrokes, both because of the sheer number and because she needs to keep them mnemonic in order to easily remember them. Therefore she uses key sequences so she can group related commands together with the same prefix. For example, she uses Ctrl+R as the prefix for all the commands dealing with revisions, with Ctrl+R followed by S to show revisions, Ctrl+R followed by H to hide revisions, Ctrl+R followed by A to accept revisions, Ctrl+R followed by R to reject revisions, and so forth.

    * Recommendation: Facilities to establish and adjust keybindings should allow content, add-ins, and the user to bind commands to key sequences as well as single keys and key combinations. HTML would let the author specify preferred keyboard inputs for accesskey and the like including key sequences, such as accesskey="ctrl+r a" for Ctrl+R followed by the letter A.

B. Allowing unmodified keys as shortcuts

Some components use unmodified letters, numbers, and punctuation marks as keyboard command. This can be handy for users who want to make keyboard input as efficient as possible, including some users with disabilities, but for other users with disabilities it can be a significant problem because everyday text input can trigger a large number of seemingly random actions if it's entered in the wrong context. Therefore user agents should be permitted to make this available as a user option.

    * Use case: Reggie finds it difficult to press key combinations, and even though many platforms provide the StickyKeys feature that lets her simulate them, she wants to author her own web site so that the shortcuts on the pages are accessed with single keys rather than key combinations.

C. Allowing non-character keys as shortcuts

Allowing non-character keys such as F12 and Del to be used as shortcuts significantly increases the number of keys and key combinations available. Currently non-character keys such as F12 cannot be assigned as accesskey shortcuts, as it can only be keys equating to single Unicode code points per 7.4.3 Processing model.

    * Use case: Jeanine is developing a Web app and because most of the normal character keys are taken, she wants to have the F12 key activate the "Exit" link on the page, and Shift+F12 activate the "Save and Exit" button.

    * Recommendation: Provide a way to use keys that cannot be represented as a single Unicode code point. For example, define keywords such as "del", "num-del" and "f12", and allow their use in the accesskey attribute along with normal Unicode characters (e.g. accesskey="f12 del d").

D. Specifying detailed shortcuts

Today's accesskey attribute is a single Unicode character, and it's up the browser to decide which whether that character will be used or another substituted, and what modifiers if any are required (e.g. accesskey="s" might map to Ctrl+S at one time and Alt+Shift+S at another). That may make sense for access keys (e.g. S or Alt+S to press the Save button) where the user agent is trying to emulate behavior of the platform, but it is an unnecessary limitation for hotkeys (e.g. keyboard inputs mapped to commands that may not be associated with a specific element).

When defining hotkeys developers of Web apps and authors of documents should be able to assign more specific keys, such as actually requesting Ctrl+I for one a frequently used command and Ctrl+Shift+I for another less frequently used. This would let them assign shortcuts in a way that is more meaningful, both in terms of grouping and being easier to remember. For example, a page for reading email could assign shortcut Ctrl+R to the Reply button and Ctrl+Shift+R to the Reply All button, Ctrl+J to the Forward button and Ctrl+Shift+J to the Forward As Attachment button, and so forth. (Of course any specific key combination may already be used by the host or another component in the system, and some keys may not be available on the user's system, so the browser would either treat these as hints to be modified as needed or else the page's script could negotiate with the user agent as described elsewhere in this document.)

    * Use case: Roger is using a Web-based email client that has a row of buttons for things he can do to the selected message. The author wanted to make keyboard usage as efficient as possible and minimize the number of keystrokes that users such as Roger need to enter, so they assigned easily typed keyboard inputs to the most commonly used commands and more complex inputs to less frequently used commands. In this case, it assigns the shortcut Ctrl+R to the Reply button and Ctrl+Shift+R to the Reply All button, Ctrl+J to the Forward button and Ctrl+Shift+J to the Forward As Attachment button, and so forth.

    * Recommendation: Facilities to establish and adjust keybindings should allow content, add-ins, and the user to bind commands to specific key combinations, rather than merely specifying a single base character. HTML would let the author specify preferred keyboard inputs for accesskey and the like including recommended base keys and modifiers (e.g. accesskey="ctrl+shift+i", using standardized, non-locale-specific names for keys and modifier keys). There should also be way for the author to request that a key be unmodified, as discussed in the section "Allowing unmodified keys as shortcuts". These recommended keyboard inputs would be modified by the browser to accommodate impossible, reserved, restricted, or conflicting inputs (as discussed in bug 13564 Negotiating shortcut keybindings). For example, when an HTML5 command element is used to create a menu item and the user agent wants to emulate native access key behavior on the Windows platform, it would limit the access key to a single character that could be used alone or with the Alt key depending on the situation, but when a command element is used to establish a hotkey for a scripted action the user agent could allow a wider range of modifiers and/or sequences.
================================================================================
 #2   Ian 'Hixie' Hickson                             2011-08-09 23:52:56 +0000 
--------------------------------------------------------------------------------
The plan is to do this in v2, once we've proved that the stuff in the spec already actually works. The idea is we'll define key labels to use in the attribute, as in accesskey="up". For sequences we might do something like "accesskey="x-s". To enable this future expansion, the spec currently limits values to one character.

I'm marking this LATER for now but will reopen this once browsers have more widely adopted what we have in the spec so far.
================================================================================