With the
accessKey HTML attribute, Web page authors can provide quick keyboard shortcuts to links and controls on a Web page. Use of the
accessKey attribute is especially important for busy pages. When the attribute is associated with an element, the user can press the ALT key with the designated access key to put focus on (in Internet Explorer 5) or activate (in Internet Explorer 4.
x) the element. If the access key is associated with an element that cannot receive focus, the screen reader user can quickly locate a particular part of the screen and start reading from that point. This provides a solution to the long standing problem of efficiently reading pages on a Web site in which parts of the page remain constant and the user must locate a part that changes.
The
accessKey technique is documented in "Accessibility Design Guidelines for the Web." A link to this article appears in the "References" section.
The Web Content Accessibility Guidelines 1.0, which the World Wide Web Consortium (W3C) outlines, recommend the
accessKey method. Internet Explorer has provided support for
accessKey beginning with version 4.0. Some Web pages have implemented
accessKey, including the Microsoft Accessibility site and the September 2000 release of Encarta Online.
However, some screen readers do not fully support
accessKey from the client side. You can test the screen reader behavior on the Microsoft Accessibility site or Encarta Online. Make sure that you test in all navigation modes that your screen reader provides (namely, normal mode, review cursor mode, and simulated cursor mode). Test with text links and other objects such as keys and check boxes. If the access key is visually underlined, use all navigation methods that Internet Explorer and the screen reader support to locate the element.
The following list outlines some common compatibility problems that screen readers experience when they implement
accessKey:
| � | When the user presses the access key, the screen reader does not read the element that is associated with that access key. |
| � | If an element has a letter that is underlined to identify the access key visually, the screen reader breaks up the voicing of the word. |
| � | If the access key is associated with an element that cannot receive focus, the screen reader goes silent and does not start re-reading from that point. |
| � | After a user uses the access key to put focus on an element, and then puts focus on other elements, that element's access key no longer takes effect. |
| � | After users apply a combination of access keys and other navigation methods (such as the TAB key or the insertion point) in the page, the screen reader tells the user that a particular element has the focus, although another element actually has the focus. |
Solutions
To avoid the common compatibility problems that were outlined earlier, assistive technology vendors should implement the following screen reader behaviors with regard to the
accessKey attribute. When the user presses an access key that is associated with an element on the page, the screen reader should:
| � | Echo the ALT+Access Key combination that the user presses. |
| � | Announce the element that gains focus (in Internet Explorer 5) or is activated (in Internet Explorer 4.x). Announce the access key that is associated with a particular element. The screen reader should also provide the user with an option to turn this feature off or on. |
| � | If the name of an element has a letter that is underlined, which identifies the access key visually, the screen reader should read the words clearly. This should occur for all methods that read the element and in all navigation modes that the screen reader supports. |
| � | Announce what occurs when users press a particular key. For example, if the user presses the access key for a Search button in Internet Explorer 5, the screen reader typically informs the user with a phrase such as "Search, push button." In Internet Explorer 4.x, screen reader may inform the user with "Search, push button, activated." Although the screen reader determines the exact user interface (UI), the screen reader must distinguish this action from the more common scenario in which an object receives focus and the screen reader merely identifies it. |
| � | If the access key is associated with an element that cannot receive focus, the screen reader should start re-reading from that element forward. |
Additional Notes
The "Accessibility Design Guidelines for the Web" article describes good keyboard navigation. It recommends that Web authors use the
accessKey attribute to provide access keys for all controls, including links that act as controls and those with underlined access keys in the control's label.
The Web Content Accessibility Guidelines 1.0 document from W3C recommends that Web authors provide keyboard shortcuts to important links, including those in client-side image maps, form controls, and groups of form controls. For example, in HTML, specify shortcuts through the
accessKey attribute.
To learn about the access keys in Encarta Online, see the Encarta Help topics (click
Help, and then search for
Shortcuts).
By clicking
Help, you can find out how to use access keys to view the Microsoft Accessibility site.
If you are a screen reader user and you experience the problems that this article describes, please contact the screen reader vendor. A new release of that product may exist that can fix these problems.