Accesskeys: Unlocking Hidden Navigation
原文地址： http://alistapart.com/article/accesskeys
Who can use your website? People with limited mobility may have a hard time controlling a mouse to click on links, and tabbing through menus can be slow going. The W3C introduced the accesskey attribute to enable users to select the appropriate key on their keyboards and navigate to a particular link.
Accesskeys can also be useful to people who have no trouble controlling the mouse and clicking on links. Experienced users of desktop applications learn to use keyboard short-cuts to save files, open new windows, or copy and paste text. Assigning accesskeys to menu items adds “Hot-Key” functions to a website, letting frequent users spend less time less time moving and clicking the mouse. This solution, however, has been largely underused because it almost always fails due to two major flaws.
The first problem is that visitors to your website have no way of knowing that you’ve assigned accesskey attributes to your linked elements. Even if they suspect you have, they would have to guess which accesskeys assignments you’ve created. In this article, we’ll look at how to solve this problem, enabling you to clearly but unobtrusively let your visitors know which accesskeys correspond with the links on a page.
A further problem that has delayed the adoption of accesskeys, is that several otherwise excellent, standards-compliant browsers still do not support accesskeys at all. (See “Accesskey Denied” for a list of non-accesskey browsers.) We can’t solve that problem here, but by pointing it out, hope to encourage browser makers to improve their support for this important web standard.
Command and Control
Windows users can navigate with the accesskey feature by typing ALT+Accesskey. On the Mac, you would use CTRL+Accesskey (not COMMAND+Accesskey, which can produce undesired effects). Internet Explorer users may also need to hit the “enter” key to activate a link.
Windows users will find that accesskeys take precedence over application commands, which can still be accessed from the keyboard by first typing the menu shortcut key (usually ALT) followed by the letter corresponding to the desired menu item.
Public Access
The accesskey is a useful feature, but most web browsers lack a standard way of presenting the letter assignments. Users could view the source code for a page to see assignments, but that defeats the purpose of making a website more accessible and user friendly. If people don’t know which accesskeys are associated with each link, they are of limited value.
The most straightforward way of letting users know which accesskeys are available and which links they correspond with is to create a help or reference page. This approach requires users to visit this page to learn how your site works before they can use the accesskeys. Anyone who doesn’t like to read manuals might be inclined to ignore this page. Unless they visit your site regularly, many users will also forget the accesskey assignments between visits.
The accesskey can be explicitly displayed, appearing in brackets immediately after each link. This is very easy to implement, and doesn’t require users to refer to a reference section before being able to use the accesskeys. However, It does force you to change both the content and design of your pages to accommodate this information. Displaying the accesskey assignments might not be relevant or useful to everyone, and some people might prefer that it not appear onscreen at all times.
Link ’Em Up
This brings us to consider less-obtrusive but still informative methods of hinting at accesskey information. Since the accesskey feature is similar to the keyboard commands in a desktop application, we can look to these interfaces for other ideas for how to display this information to users.
Menus in applications often have a single letter underlined that corresponds to the keyboard shortcut for that item. Since many users will be familiar with this convention, we can use it to indicate the accesskey assignment for a link. By underlining a single letter and setting it as a link element’s accesskey attribute, users will know which accesskeys correspond with each link.
While there is an underline tag, it became deprecated in HTML 4.0 and should no longer be used. Instead, we’ll place emphasis tags around the first letter of each link:
Home
We can then use a CSS contextual selector to define that emphasized text within a link will be underlined, while the text in the rest of the link will not. We can also set the style and weight of the emphasized text so that aside from the underlining, it matches the rest of the link. A rollover effect could also be added to underline the entire link by using the :hover pseudo-class:
a {
text-decoration: none;
}a em {
font-style: normal;
font-weight: normal;
text-decoration: underline;
}a:hover {
text-decoration: underline;
}
This technique is relatively easy to implement, works with most modern web browsers and allows you to underline any letter within a link to indicate the accesskey attribute. However, it does require you to add <em> tags to all the links with accesskeys in your documents.
(Jeff McCartney suggested that I consider underlined characters to indicate accesskeys, and has since implemented this technique for The Ontario Ministry of Energy.)
First Impressions
The next method we’ll look at uses a CSS 2 pseudo-element to specify that the first letter in our links is underlined, while the remainder of the text is not. This approach doesn’t require you to change the actual content of the document, allowing you to keep style and content separate:
a { text-decoration: none;}a:hover { text-decoration: underline;}a:first-letter { text-decoration: underline;}
The :first-letter pseudo-element controls the style of the first rendered character of a block element. Since links are normally inline elements, this wouldn’t apply to the first letter of any regular links on a page. The only links that would have their first letter underlined would be those that were also set to display:block.
By using a custom class we can underline the first letter in our menu items while not affecting the rest of the content on the page. we’ll use this code a little later in the article to build a pure css menu:
.menu a {
display: block;
width: 150px;
}
WEB BROWSER BLUES
Netscape 7 supports the :first-letter pseudo-element being applied to a link quite well, but Internet Explorer’s support is somewhat buggy. To work, it must be applied directly to the link element, without use of custom classes or IDs. Furthermore, once applied to a link element it seems to interfere with Internet Explorer’s ability to use the :hover pseudo-class to create rollover effects.
The fix, strangely enough, is to make sure there is a style for a link within a custom class included somewhere in your style sheet. Something like this:
.content a {
color: #f30;
background-color: transparent;
}
The actual attributes you set don’t seem to matter — the very existence of a rule for a link within a custom class seems to be enough to fix this bug. If your style sheet doesn’t normally include this type of rule, just add this extra one to fix the bug:
.ie_fix a { text-decoration: none; }
Using the first-letter pseudo-element with a link element doesn’t work for some Opera and Gecko-based browsers. The first letter of your links won’t be underlined in these browsers, but we can use another technique to display accesskey information to these users.
Pseudo Generation
The CSS 2 :before and :after pseudo-elements can create content and insert it into the document. The content created in this manner can include counters, embeddable objects, images, and strings of text. This text can be dynamically generated from the content of one or more of the parent element’s attributes. When applied to a link these attributes include the URL, title, language, link-type, and the one we’re focusing on: accesskey.
This code will insert the accesskey assignments in parentheses immediately after each link on a page without changing the underlying content of the document:
a:after {
content: " [" attr(accesskey) "] ";
}
Displaying this information makes accesskey more useful, but as we mentioned earlier, many people would prefer that it not appear onscreen at all times. Fortunately, we can give users some control over when to include this information.
SELECTIVE DISPLAY
We can selectively display CSS-generated content by using a style sheet switcher to change the CSS files used to display the page. People will then have the option of choosing a style with enhanced accessibility options, including the display of the accesskey attribute after each link. If they don’t want to see this information onscreen, they can select a style sheet that doesn’t include the CSS generated content. The ability to use the accesskey feature will still be available all users, regardless of the style sheet they are using to view the page.
A second method for selectively displaying accesskey information, is to make use of a contextual selector to specify that the generated content is only displayed when the user rolls over a link. The :after pseudo-element is added to the the :hover pseudo-class in the selector chain that is applied to the link element.
we’re looking at ways to improve support for keyboard navigation, so we’ll also use the :focus pseudo-class, which changes the appearance of a link when a user tabs onto it, rather than moving over it with their mouse. We can set the CSS properties for both :hover and :focus at the same time by using a comma to group the two contextual selectors together:
a:hover:after, a:focus:after {
content: " [" attr(accesskey) "] ";
}
The generated accesskey text that appears when a link is tabbed or rolled over may cause the surrounding elements and text to shift to accommodate the changing length of the link. This can create an undesirable visual disruption as lines of text change their position on the page. Displaying accesskey information during a rollover works best when the link element has a fixed width, as might be the case with menu items.
CSS Menu with Accesskey Info
we’ll use both of the CSS techniques we’ve covered to create a menu that displays accesskey information. You can refer to CSS Design: Taming Lists for more detailed instructions on using style sheets to create menus from bulleted lists. Some browsers such as Internet Explorer will display these menu items with the first letter underlined. Other browsers, such as Mozilla will display the accesskey when the the menu item is rolled over or focused. Some browsers, like Safari, will display both types of accesskey hints. All browsers that support this feature will be able to use the accesskeys regardless of the manner in which they are displayed.
<!—The ALA template already has a div with id=“menu” so we’ll use “akmenu” instead.—>
Our menu was created using the following markup:
We’ll place our list within a DIV given the ID “menu”. Our style sheet rules can then use this ID to apply to this specifc list, while leaving any other lists on the page unaffected:
a { text-decoration: none;}a:hover { text-decoration: underline;}a:first-letter { text-decoration: underline;}
.ie_fix a { text-decoration: none; } #menu {
width: 8em;
border: 1px solid #000;
border-top: none;
padding: 0;
color: #333;
}#menu ul {
list-style: none;
margin: 0;
padding: 0;
border: none;
}
#menu li {
border-top: 1px solid #333;
margin: 0;
}#menu li a {
color: #003366;
background-color: #fff;
display: block;
padding: 5px 5px 5px 0.5em;
text-decoration: none;
width: 100%;
}html>body #menu li a {
width: auto;
}
#menu li a:hover {
background-color: #003366;
color: #fff;
}
#menu li a:hover:after, #menu li a:focus:after {
content: " [" attr(accesskey) "] ";
}
{Ed. Note: Since this article was first published, a few color and size values have been changed to better match the ALA 3.0 template.}
Accesskey Denied
The accesskey attribute is currently supported by the following web browsers:
- Internet Explorer 4+ (Windows) 5+ (Mac)
- Mozilla (Windows + Linux)
- Netscape 6+ (Windows)
- Opera 7 (Windows + Linux)
Other web browsers including Camino, Galeon, Konqueror, Omniweb, and Safari have otherwise excellent support for web standards, but have yet to include this W3C-recommended feature.
Moving Forward
Providing support for keyboard navigation makes a website easier for everyone to use. Browser manufacturers can help by ensuring their products include better support the accesskey attribute. I hope some of these suggestions will encourage you to begin experimenting with accesskeys.
