This document proposes a replacement specification of the HTML accesskey attribute, to improve the possibilities for Web applications that want user interaction to trigger functionality.

This is a draft proposal to replace the "accesskey" section of the W3C's HTML specification. in order to . It is under discussion in the Web Incubator Community Group for adoption as a proposed change to the HTML specification. The topic has also been discussed in the HTML accessibility Task Force

Issues for this document are tracked on github, and anyone should feel welcome to raise issues there. The repository also includes test cases and result information. Direct proposals for change in the form of Pull Requests are welcome, preferably with reference to an issue that explains the change, unless it is something simple like a typo.


Rationale for this extension

The definition of accesskey in HTML5 is a clear improvement on the HTML 4 accesskey definition, for example allowing for multiple keys to cope with different user environments. However, there are still a number of problems:

Few browsers, given a value for the attribute that is larger than a single character, assign any shortcut activation at all. Few if any assign one in the case where multiple characters are used. Only Firefox implements the DOM accessKeyLabel attribute, and that implementation is both fragile and not according to the HTML5 specification.
Javascript shortcuts break user expectations
Because implementation of accesskey in browsers has been of poor quality, for many years the most common approach to providing shortcuts has been to use javascript to trap user Interface events. This is worse than the problem it attempts to resolve:
  • it interferes with normal user agent behaviour, unpleasantly surprising some users
  • there is no discoverability mechanism for javascript-based activations. This is a particular problem when combining javascript libraries and/or browser extensions
Improving accesskey to the extent that it can easily replace the benefits of the javascript approach, while mitigating its drawbacks, is a major motivation for this extension.
Conflict resolution
The current specification allows the User Agent to determine "what keys are available", from the author's suggested values for accesskey. However, its algorithm is too limiting, failing to take into account the point that the "first available key" may not be the one most appropriate for the user.
In the current HTML specification there is no requirement for discoverability. This is a major problem with existing implementations, very few of which provide a means for the user to discover that accesskeys have been assigned. Instead the current specification assumes that authors will somehow present the required information to the user. For a browser-mediated interaction, this is inappropriate, placing the burden of work in the wrong part of the "hierarchy of needs" and making it less likely to be done, or done effectively. While the HTML specification has rightly shied away from specifying user interfaces, it should at least be clear when there is a need for user interface if a functionality is going to work.
Ecosystem requirements
The current HTML specification assumes all shortcuts assigned will be key combinations. This does not meet the reality of deployed platforms, many of which either do not have a keyboard or also permit other activations more appropriate for a shortcut.
In addition, the current HTML specification fails to provide sufficient context to motivate the use of a shortcut, including when it is not useful, or when another method may be more appropriate.

Proposed Replacement Section 5.5:

5.5 Assigning activation shortcuts

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.

In this example, an author has provided a button and requested a shortcut activation. The author has suggested the russian word "Написать", the latin keys "w" and "c", and the number "1" as useful hints for what makes sense as shortcut activations.

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

A browser might apply this by adding a voice command "Написать" to a grammar of expected commands for which an event can be fired, by listening for keypresses of the Cyrillic letters "Н" (equivalent to the latin "n") or "П" (equivalent to latin "P") or one of the letters proposed by the author, perhaps with a standard modifier.

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.

To tell the user what the shortcut key is, this script explicitly adds the browser-described shortcut activation to the button's label:

function addShortcutKeyLabel(button) {
  if (button.accessKeyLabel != '')
    button.value += ' (' + button.accessKeyLabel + ')';

Different browsers on different platforms can show different labels, even for the same key combination.For example, if the activation shortcut is the Control key, the Shift key, and the letter C, a Windows browser might display "Ctrl+Shift+C", whereas a Mac browser might display "^⇧C", and an Emacs browser might just display "C-C". Where a voice command enabled, the value might be "^⇧C or say "compose".

It is therefore unwise to attempt to parse the value returned from the accessKeyLabel IDL attribute.

Given a standard microsyntax for commands, accessKeyLabel would be parseable. In any event, there is currently only one implementation - is it consistent across platforms?

For gestures, it is useful to present an animation of the gesture. Can we enable this?

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.

In the following example, a set of links are given accesskeys so that users familiar with the site can quickly navigate to relevant pages:

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

In the following example, a search field is identified using the standard HTML technique input type="search". A link to an advanced interface is available, but there is no standard HTML technique for identifying a "more advanced" version. Assuming that advanced search is a relatively common user interaction on this site, an accesskey attribute is present to request an activation shortcut, and the application has suggested three possible access keys, "advanced", "s" and "9" in that order. A user agent on a device with a "QWERTY" keyboard might pick the combination Ctrl+Alt+A as the shortcut if it is available, first falling back to Ctrl+Alt+S and then Ctrl+Alt+9. A user agent on a small device with a telephone keypad might pick just the plain unadorned key 9:

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

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.

In the following example, a button has possible access keys described. A script then tries to update the button's label to advertise the shortcut the user agent selected.

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

<!-- ... -->

 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")

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.

Changes from the HTML 5 definition

This specification introduces a number of changes to the HTML5 definition of accesskey:


Many thanks to Robin Berjon for making spec editing easier with Respec.

This is a piece of work that has developed over almost two decades, and a great many people have made important contributions. As well as all the the people who worked on the original accesskey specification in HTML 4 and the access element proposed for XHTML2, and many people who deserve a mention but are not noted here, the editor owes explicit thanks to Cynthia Shelly, David MacDonald, Deborah Kaplan, Dominic Mazzoni, Earl Johnson, Emmanuelle Gutiérrez y Restrepo, Ian Hickson, Johannes Wilm, John Foliot, Jonathan Avila, Judy Brewer, Jukka Korpela, Léonie Watson, Philippe le Hégaret, Rafael Romero, Richard Schwerdtfeger, Rodney Rehm, Ryosuke Niwa, Shane McCarron, Simon Pieters, Stuart P Bentley, Taylor Hunt, and the Paris Web community for direct contributions that have improved this document.