Overview

Keyboard shortcuts are a good idea for software design, and would be a great idea for web design too, if there were better ways of making keyboard shortcuts available to users. The accesskey HTML attribute allows web developers to assign keyboard shortcuts to web elements, but the specification was vague and incomplete. As a result, developers of browsers and assistive technologies implemented 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 faster interaction 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 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, According to the Specification

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:

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 result has been an almost complete failure of the idea to take hold in user agents and web development practices.

Browser implementation

Browser implementation varies widely between brands and operating systems. Still, the basic idea behind accesskey shortcuts is fairly consistent, even though implementation varies. Users can get accustomed to the way their favorite browser handles accesskey shortcuts, but may have to learn new methods if they switch to another browser.

Keystroke combinations

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

Alt + [the accesskey]

Internet Explorer for Windows

Chrome for Windows (not that Shift is required in some circumstances

Safari for Windows

Shift + Alt + [the accesskey]

Firefox for Windows

Ctrl + Option + [the accesskey]

Safari for Mac

Chrome for Mac

Firefox for Mac

Duplicate accesskey values

Most browsers do not support duplicate accesskey attribute 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 elements 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 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 Internet Explorer. Some, though not all, screen readers will indicate the accesskey value when the element is enountered.

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 user agents (browsers) and those defined 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? How this type of conflict is managed also depends upon the browser.

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. This has the potential to cause confusion and frustration in users. What if the user wants to access the File menu, but is unable to because of an accesskey on the web page which uses the F key? 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. This is of primary concern because screen reader users are usually reliant on keyboard accessibility and are thus a primary beneficiary of accesskey functionality. If a screen reader keyboard shortcut is disabled by an accesskey shortcut, the user may not be able to perform important screen reader functions.

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

Language issues

Are there any keystrokes that do not conflict with any browsers, assistive technologies, or operating systems? In short, no. All of the keystrokes 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 named "File" in languages other than English. The software may say "Archivo" (Spanish), "Dossier" (French), "Lima" (Italian), "Ficheiro" (Portuguese), "Akte" (German), or some other word in a different language, all of which may use different keyboard shortcuts.

Numerals

Because of the fact that every letter is presumed taken already by some function, some accessibility experts have advocated for the use of numerals, rather than letters, in order to minimize the overall impact of keyboard shortcut conflicts. It is true that there are fewer potential conflicts for numerals than for the letters, though lack of conflicts are not guaranteed. This does not necessarily mean that numerical values are off-limits. They will indeed work for many or most users. Additionally, there usually is no direct association between numbers and page functionality, making the user of numerals more complex and potentially confusing to users.

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 identify accesskey shortcuts for users, and indeed some screen readers do this. But this is not helpful for sighted keyboard users. This should not be the responsibility of the developers at all. Nevertheless, since this ideal scenario does not exist, if developers choose to use accesskey shortcuts, they must somehow notify users that the accesskey shortcuts are available. Some 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; all users know which keystroke combination to use (is it Alt, Ctrl, Shift, etc.?).

Putting the accesskey in parentheses, for example: Next Page (Access key: N)

Advantages: Easy to implement. All users will be able to read the text.

Disadvantages: This 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 is being used, for example: Next Page (Alt + N)

Advantages: This 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: This 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, in which case the file may be long and awkward.

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.

Should Accesskey Be Used At All?

The answer to the question of whether accesskey shortcuts should be used at all is not always an easy one. Due to the numerous problems in implementation, many developers choose to avoid them entirely—even developers who are staunch accessibility advocates. Even so, if they are implemented carefully, accesskey shortcuts can be beneficial to some users, particularly in closed environments with web applications where accesskey can make repeated processes more efficient. This is really a matter of personal preference, with the realization that some users will benefit and some will not, or could even be disadvantaged, by you implementing accesskeys.