WebAIM - Web Accessibility In Mind

Keyboard Accessibility


Keyboard shortcuts are a good idea for software design, and if there were better ways of making keyboard shortcuts available to all users, they would be a great idea for web design too. The accesskey HTML attribute allows web developers to assign certain keyboard shortcuts to web elements. Developers of browsers and assistive technologies implement accesskey support inconsistently and ineffectively. Web developers can still use accesskey to create keyboard shortcuts, but there are many considerations to take into account.

Keyboard Shortcuts as a General Concept

Keyboard shortcuts can be useful to all computer users because they often allow for interactions that are faster than allowed by mouse clicks. "Power users" of all abilities frequently use keyboard shortcuts. Among people with disabilities, people who are blind or who have motor disabilities also make frequent use of keyboard shortcuts.

Keyboard shortcuts are a standard accessibility feature of most operating systems. Microsoft and Apple, for example, have standardized these keyboard shortcuts to make it easier to access menus and functions quickly, without having to use a mouse.

Part of the convention of standardized keyboard shortcuts in Windows is to underline the letter of the character that serves as the keyboard shortcut. On Windows, the letter "F" in the word "File" is underlined as a cue to users that a keyboard shortcut is present, and indicates which key activates the shortcut. On the web, however, there is currently no standard convention for defining or indicating per-page keyboard shortcuts.

The accesskey Attribute

Starting with HTML 4.0, the accesskey attribute can be added to interactive HTML elements, such as links and form controls. The attribute is simply added within the element, as in the examples below:

<a href="http://webaim.org/" accesskey="w">WebAIM.org</a>
<form action="submit.htm" method="post">
<label for="name">Name</label>
<input type="text" id="name" accesskey="n">
<input type="submit" id="submitform" accesskey="s" value="Submit">

The accesskey attribute defines a shortcut to the specified destination. In the examples above, the "W" accesskey would take the user to webaim.org. The "N" accesskey would take the user to the text input field, and the "S" accesskey would submit the form.

A Good Idea Implemented Poorly

Unfortunately, the recommendations are rather vague as to how best to implement keyboard shortcuts. Browser developers, assistive technology developers, and web content developers were left to chart their own course. Despite good intentions, the practice has failed to take hold in user agents and web development practices.

Browser implementation

Browser implementation varies widely between brands and operating systems, but the basic ideas behind accesskey shortcuts are fairly consistent. Users become accustomed to the way their favorite browser handles accesskey shortcuts, and may have to learn new methods when switching to another browser.

Keystroke combinations

Different browsers use different keystrokes to activate accesskey shortcuts, as shown below:

  • Common Windows Browsers: Shift + Alt + [the accesskey]
    • Shift is optional in some browsers.
  • Common Mac Browsers: control + option + [the accesskey]

Duplicate accesskey values

Most browsers do not support duplicate accesskey values. For example, a page cannot have two shortcuts with accesskey="1". Most browsers will ignore one of the shortcuts. Some browsers ignore the first instance, and other browsers ignore the second instance. Some cycle through the shortcuts with each successive accesskey keyboard activation.

Additionally, with HTML5, an element may have multiple accesskeys (e.g., <a href="home.htm" accesskey="1 h">Home</a>). Support for multiple values also varies greatly across browsers.

Activating accesskey element

Implementation also varies on what activating the appropriate accesskey keyboard combination will do. Some simply set focus to the element that has the accesskey (the user must then press Enter to activate it), whereas others will immediately activate it. This varies even more depending on the type of element — links, buttons, and form controls may all behave differently.

Screen reader implementation

Because screen readers depend upon browsers for much of their functionality, screen reader implementation of accesskey is largely dependent upon the browser being used. Screen readers that work with Internet Explorer, for example, behave in the same way as the Internet Explorer browser. Some screen readers will indicate the accesskey value when the element is encountered.

Browser conflicts

One of the distinct issues with the whole idea of accesskey is that there are bound to be conflicts between the keyboard shortcuts of browsers, operating systems, browser extensions, etc. and those defined in the web content. For example, Alt + F on a standard Windows program will activate the File menu. What happens when a web developer wants to use the same keyboard combination to access a part of the web page, such as a File menu inside a web application? The user's browser will determine how this type of conflict is managed.

In the case of Internet Explorer for Windows, Firefox, and most other Windows-based browsers, the accesskey in the web page takes precedence over the keyboard shortcut of the user agent. Keyboard shortcut users may experience confusion and frustration in this situation. Web developers cannot assume that users will know how to use accesskey shortcuts, or to know how to handle accesskey conflicts.

Screen reader conflicts

One of the biggest concerns with accesskey shortcuts is the possibility of the accesskey overriding the keyboard shortcuts of screen readers, which have many more keyboard commands than standard browsers. Keyboard shortcuts are a critical component of a screen reader's functionality, so screen reader users can greatly benefit from the proper use of the accesskey. Conversely, if a screen reader keyboard shortcut is disabled by an accesskey shortcut, a screen reader user may be prevented from performing important screen reader functions.

In cases of conflicts, the screen reader shortcuts generally take precedence, meaning that the accesskey shortcuts are effectively disabled, even though they will still be identified to the user. The accessibility benefit of accesskey shortcuts is lost, but screen reader functionality is left intact. This, however, may be confusing if the user wants to activate an accesskey.

Language issues

Are there any keystrokes combinations that do not conflict with any browsers, assistive technologies, or operating systems? In short, no. All of the standard keystroke combinations are either already known to conflict with existing software, or may in the future conflict with software not yet developed. This is especially true when foreign languages are taken into account. The File menus in browsers are not always named "File" in languages other than English. As such, an accesskey shortcut may not cause a conflict in a browser set to use English, but may cause a conflict in the same browser when it's set to use another language.


Because every letter is already presumed to be associated with a web function, some accessibility experts have advocated for the use of numerals—rather than letters—to minimize the overall impact of keyboard shortcut conflicts. Although there are fewer potential conflicts with numerals—lack of conflicts is by no means guaranteed. This does not mean that numerical values are off-limits—they will work for many users—but remember that there are no standard associations between numbers and web page functionality. Users may be confused by the use of numerals in keyboard shortcuts.

How do users know if accesskey shortcuts are available?

One of the biggest problems with accesskey shortcuts is that users are not generally aware that they even exist, and there is no standard way of notifying them. Unlike the Windows environment, which underlines the letter of the keyboard shortcut in menus, there is no convention or "rule-of-thumb" for alerting users to the presence of an accesskey shortcut. Developers may choose to mimic the conventions of the Windows environment, or they may invent their own. All of these efforts, though well intentioned, fall short of the ideal.

The ideal would be to have the user agents (browsers, screen readers, etc.) identify the available accesskey shortcuts for users. Some screen readers already do this, but that doesn't help sighted keyboard users. Developers that choose to use accesskey shortcuts must notify users that the accesskey shortcuts are available. Methods of accomplishing this are:

  • Underlining the letter within a word that activates the accesskey, for example: Next Page.
    • Advantages: Easy to implement; some users will recognize this convention.
    • Disadvantages: Not all users will recognize this convention; not all users will know which keystroke combination to use (is it Alt, Ctrl, Shift, etc.?).
  • Putting the accesskey in parentheses, for example: Next Page (Accesskey: N)
    • Advantages: Easy to implement; all users will be able to read the text.
    • Disadvantages: Changes the layout and look and feel of the web content; not all users will recognize this convention; not all users know which keystroke combination to use.
  • Put the exact keystroke combination in parentheses, depending on which browser and operating system is being used, for example: Next Page (Alt + N)
    • Advantages: Tells the user exactly what keystroke combination to use.
    • Disadvantages: Requires browser detection scripts, either with JavaScript or server-side scripts; changes the layout and look and feel of the web content.
  • Create a list of accesskey shortcuts on a separate page and linking to them from all pages on the site that use the accesskey shortcuts.
    • Advantages: Puts all of the keyboard shortcuts in one place for easy reference.
    • Disadvantages: Users must go to a separate page in order to learn the keyboard shortcuts; requires the addition of an extra link on every page; users still may not know which keystroke combination to use (Alt, Shift, etc.) unless it is explained in the external file (which may be a long and awkward document).
  • Use more sophisticated CSS and/or browser detection approaches that expose the accesskey shortcuts when the elements receive focus or when the mouse hovers over them.
    • Advantages: Does not interfere with visual layout; if both CSS and browser detection are used, then users can be notified of the exact keystroke combination necessary.
    • Disadvantages: Requires a working knowledge of advanced CSS and/or browser detection scripts.
  • Use some combination of the above approaches.

Should Accesskey Be Used At All?

The answer to this question is not an easy one. Due to numerous problems with implementation, many developers choose to avoid them entirely—even developers who are staunch accessibility advocates. Even so, if they are implemented carefully, accesskey shortcuts are beneficial to some users. For example, in a "closed environment" web application, accesskeys can make repeated processes more efficient. The bottom line: some users will benefit and some will not, and some may even be disadvantaged.