[Bug 19044] New: Extend accesskey="" to accept key names (e.g. accesskey="home")

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19044

           Summary: Extend accesskey="" to accept key names (e.g.
                    accesskey="home")
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: a11y, a11ytf
          Severity: normal
          Priority: P2
         Component: HTML5 spec
        AssignedTo: dave.null@w3.org
        ReportedBy: contributor@whatwg.org
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org,
                    laura.lee.carlson@gmail.com,
                    public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org, public-html-a11y@w3.org


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

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 25 September 2012 21:59:15 UTC