Keyboard shortcuts can be helpful in making applications more efficient. The
accesskey HTML attribute allows web developers to assign certain keyboard shortcuts to web elements. However, because browsers and assistive technologies implement accesskey support inconsistently, ineffectively, or not at all, the
accesskey attribute should typically be avoided or implemented with great care.
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. Visual interfaces often indicate the standard keyboard commands for common functions. On the web, however, there is currently no standard convention for defining or indicating per-page keyboard shortcuts.
accesskey attribute can be added to interactive HTML elements, such as links and form controls, as in the examples below:
<form action="submit.htm" method="post">
<input type="text" id="name" accesskey="n">
<input type="submit" id="submitform" accesskey="s" value="Submit">
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
Despite good intentions and because of varied and insufficient browser implementations, accesskey very often does not provide a viable solution for keyboard shortcuts on the web.
Browser implementation varies widely between brands and operating systems, but the basic ideas behind accesskey shortcuts are fairly consistent. Users must learn the key combinations for activating accesskey shortcuts, and may have to learn new key combinations for activating them when switching to another browser or operating system.
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". If present, most browsers will support at most one of the elements. Some cycle through the elements with each successive accesskey keyboard activation.
With HTML5, an element may have multiple accesskeys (e.g.,
<a href="home.htm" accesskey="1 h">Home</a>). Support for multiple values varies greatly across browsers.
Activating accesskey functionality
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. Some screen readers will indicate the accesskey value each time the element is encountered. This can introduce unnecessary noise and repetition once the user has oriented to that accesskey.
Conflicts between accesskey shortcuts and the keyboard shortcuts of browsers, operating systems, assistive technologies, browser extensions, etc. are common. When conflicts are present the ambiguity of what will occur can cause confusion. Users may inadvertently trigger unintended actions.
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 (or vice versa), a screen reader user may be prevented from performing important functionality.
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.
There are no keystroke combinations that are sure to pose no potential conflict with any browsers, assistive technologies, or operating systems. This is especially true when foreign languages are taken into account. A File menu, for example, is 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 have advocated for the use of numerals—rather than letters—to minimize the potential for keyboard shortcut conflicts. Although there are fewer potential conflicts with numerals—lack of conflicts is by no means guaranteed. 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?
In web pages or applications there is no standard way of informing users which accesskey shortcuts are available. 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.
While screen readers typically identify the accesskey shortcuts for interactive elements when encountered, this doesn't help sighted keyboard users. Developers that choose to use accesskey shortcuts must notify users that the accesskey shortcuts are available by underlining the letter within a word that activates the accesskey, spelling out the accesskey or key combination (which will vary by browser and operating system) in text, or by providing a list of shortcuts in the page or in help documentation. None of these provide a consistent, readily-available, and intuitive method for informing all users.
Should Accesskey Be Used At All?
The answer to this question is not an easy one. Due to numerous problems with implementation, accesskey is typically best avoided. If used, they must be implemented carefully. The bottom line: some users will benefit and some will not, and some may even be disadvantaged.
Alternatives to accesskey
Caution must be taken when defining custom shortcuts. Single-key shortcuts to perform functionality (such as S to open a search form) can be used. However, these may conflict with other shortcuts and may be inadvertently activated, especially by users of voice control software. If single-key shortcuts are provided, users must be given the option to disable them or remap them to a multi-key shortcut (e.g., change to Shift + Alt + S for search).