5.5.1 Introduction

This section is non-normative.

Some common browsing functions have multiple "shortcut" activations: going back in history, following a link or selecting an item in a form menu may be done through "pressing" an onscreen button, a keystroke, a gesture, or other command. Likewise, in many web apps, especially those that users interact with often such as webmail, applications for work, or common recreational sites, it is helpful to provide activation that minimises the amount of physical work a user needs to do. Typically, these are features remembered by frequent use, but it is important that users can discover them and that they meet the particular needs of a user, in order to be a genuine shortcut.

HTML lets authors request shortcut activations for any element that can receive focus or be activated, using the accesskey attribute. Authors can provide several suggestions for shortcuts in the accesskey attribute.

Authors should not request shortcuts for normal browser function. Where HTML already provides a way to indicate something the browser can act on, such as using rel="help" to identify a link to a help interface, it is better to use these features than to assign an accesskey attribute.

Currently the rel attribute only applies to a, area, and link elements. Should it be extended to cover e.g. elements with role="link" or interactive elements which can take on the functionalities of a link defined with a role="…"?

The actual shortcut(s) assigned, such as a key combination or direct access voice command, is determined by the user agent, using information about the user's preferences, keyboard, what shortcuts exist on the platform, and what other shortcuts have been specified on the page, as well as the information provided in the accesskey attribute.

<input type="button" value="Написать" onclick="compose()"
       accesskey="Написать С W 1" id="Написать">

The user agent is best-placed to inform the user that there are shortcut activations for the page, and explain the particular activation shortcuts and what they will do. But HTML also provides an accessKeyLabel DOM attribute, which is text created by the user agent describing the shortcut. Applications can use this to reinforce the information that a shortcut is available.

function addShortcutKeyLabel(button) {
  if (button.accessKeyLabel != '')
    button.value += ' (' + button.accessKeyLabel + ')';
}
addShortcutKeyLabel(document.getElementById('c'));

5.5.2 The accesskey attribute

All HTML elements may have the accesskey content attribute set. The accesskey attribute's value is used by the user agent as a guide for creating a shortcut that activates or focuses the element.

If specified, the value must be a potentially empty ordered set of unique space-separated tokens that are case-sensitive.

Authors should give a value to the accesskey attribute, that is a single character, for backward compatibility.

At the time of writing, if the value is more than a single character many browsers will not provide any shortcut, therefore reducing accessibiltiy and usability of the author's application.

<nav>
 <p>
  <a accesskey="Activity a" href="/Consortium/activities">Activities</a> |
  <a accesskey="TR" href="/TR/">Technical Reports</a> |
  <a accesskey="S" href="/Consortium/siteindex">Site Index</a> |
  <a accesskey="B" href="/Consortium/">About Consortium</a> |
  <a accesskey="C" href="/Consortium/contact">Contact</a>
 </p>
</nav>

<form action="/search">
 <label>Search: <input type="search" name="q"></label>
 <a href="advanced.html" accesskey="advanced s 9"
 <input type="submit">
</form>

User agents should indicate whether a page has shortcuts assigned, and if so should provide users with a list of the current shortcuts for a page. The accessKeyLabel IDL attribute returns a string representing the actual shortcut assigned by the user agent.

There are a variety of interaction strategies that could be used to meet this requirement. Opera 12, and Opera mini, enabled a menu that presented the activation shortcuts enabled and what they did. iCab and many old phone browsers added icons to the screen. The excesskey extension for Opera added an icon and menu to the browsers User Interface alerting users to the fact that shortcuts were enabled. Some screenreaders announce a shortcut verbally. This specification does not recommend a specific user interface, because that inherently depends on the nature of the user agent.

<input id="compose" type=submit accesskey="N @ 1"
  title="write a new email message" value="Compose">

<!-- ... -->

<script>
 function labelButton(button) {
   if (button.accessKeyLabel)
     button.value += ' (' + button.accessKeyLabel + ')';
 }
 var inputs = document.getElementsByTagName('input');
 for (var i = 0; i < inputs.length; i += 1) {
   if (inputs[i].type == "submit")
     labelButton(inputs[i]);
 }
</script>

5.5.3 Processing model

An element's assigned shortcut(s) are user behaviours, determined by the user agent. They are derived from the presence of an accesskey attribute, and normally take into account the content of that attribute.

User agents must maintain a list of possible shortcuts, which are input behaviour it can recognise. These can be gestures, a grammar of commands, a set of key combinations, or combinations of these and any other input behaviour the user agent can recognise. This list should be configurable by users.

For example, by default a user agent may define the letters a-z, the cyrillic letters а-я, and the greek letters α-ω, each in combination with the "shift" and "alt" keys, as possible shortcuts.

User agents should maintain a list of currently assigned shortcuts.

Whenever an element's accesskey attribute is set, changed, or removed, the user agent must update the element's assigned access key by running the following steps:

This algorithm is intended to ensure that when shortcuts are requested a shortcut is assigned if possible. Shortcuts are assigned with user preference having higher priority than browser default behaviour, and author suggestion having lower priority. Multiple shortcuts may be assigned, and the same shortcut may be assigned to multiple elements.

1. If the element has no accesskey attribute, stop.

2. If the user agent has a default interaction assigned to focus or activate the element, it may stop processing.

   For example, if the element has an assigned shortcut based on a rel attribute value, the user agent is not required to assign a further shortcut.

3. If the user agent has a stored user preference for activation of the element, let keys be the value of that preference and skip to the assign step below.

4. Otherwise, let keys be null, split the attribute's value on spaces, and let tokens be the resulting tokens.

5. Process each value in tokens, in the order they appeared in the attribute's value, according to the following substeps:

   1. if the value corresponds to a possible shortcut:

      What values correspond to a possible shortcut is left as an implementation detail. If the possible shortcuts include the 26 letters of the english/latin alphabet, each in combination with the modifier keys "Control" and "Shift" and "alt", then the values "a", "adjust", and "A" may correspond to the shortcut "ctrl-shift-alt-a". The value "ф" (a cyrillic character usually transliterated to latin as "f" may correspond to a value of "a", since on a qwerty keyboard it corresponds to the same physical key. The token values "ñ", "ж" and "語" are unlikely to correspond to a "possible shortcut" value of "a".

      1. if the value corresponds to an assigned shortcut, the user agent may continue processing tokens.

         This enables the user agent to avoid assigning the same shortcut twice

      2. Otherwise add the value to keys. The user agent may continue processing tokens.

         This allows the user agent to assign only a single shortcut - although that is also possible through the requirements in the "assign" step.

   2. Otherwise, continue processing the tokens

6. assign: If the value of keys is not null, assign one or more of the corresponding possible shortcuts.

   The user agent is not required to assign more than a single shortcut to a given element.

   What happens if the user agent runs out of shortcuts?

7. Fallback: The user agent should assign a possible shortcut.

8. If this step is reached, the element has no assigned shortcut.

Once a user agent has selected and assigned a shortcut activation for an element, the user agent should not change the element's assigned shortcut unless the accesskey content attribute is changed or the element is moved to another Document.

When the user triggers the behaviour corresponding to the assigned shortcut for an element, for example by making a gesture or pressing a key combination, the command's Hidden State facet is false (visible), the command's Disabled State facet is also false (enabled), the element is in a Document that has an associated browsing context, and neither the element nor any of its ancestors has a hidden attribute specified, then the user agent must move the focus to the element with a corresponding assigned shortcut.

If the element defines a command, and the assigned shortcut is unique to that command, the user agent should trigger the Action of the command.

Issue #15 - why not require activation?

The accessKey IDL attribute must reflect the accesskey content attribute.

The accessKeyLabel IDL attribute should return a string that represents the element's assigned shortcut(s), if any. If the element has none, then the IDL attribute must return the empty string.