Accesskeys: Unlocking Hidden Navigation

by
Published in Accessibility, Browsers, CSS, HTML

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.

Article Continues Below
Article Continues Below

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#section2

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#section3

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#section4

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#section5

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#section6

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#section7

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#section8

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#section9

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#section10

The accesskey attribute is currently supported by the following web browsers:

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#section11

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.

126 Reader Comments

  1. Seeing as Lynx is very likely to be used without a mouse it seems a shame it doesn’t support access keys.

  2. Our intranet use Accesskeys extensively (we have set it as a usability requirement in every interface). We have added a small piece of code to every link – removing the need to hit Enter (as described in the article).

    Like this:

    Zociety Magazine

    When you hit ALT+Z the onfocus code will force the browser to go to the specific link immidiately.

    PS: Our internet is accessed trough a custom made browser (for security and usability reason), so I have never tested this using other browsers – but it should work.

    The code is also fully accessible – even in browsers that do not support javascript.

  5. Neat, but users who need access keys most may never see them. I like to been underline the access key letter in the label text. Doing this manually is a pain, but it’s fine if you let the server do the work for you. For those of you who use Java/JSP, here is a simple function that does the necessary:

    protected String getLabelTextWithAccelerator ()
    {
    String strLabelText = m_strLabelText;
    if ((accesskey != null) && (m_strLabelText != null))
    {
    // First character only
    String strAccesskey = accesskey.toLowerCase ().substring (0,1);
    int idx = m_strLabelText.toLowerCase ().indexOf (strAccesskey);
    if (idx >= 0)
    {
    strLabelText = m_strLabelText.substring (0, idx) +
    “” +
    m_strLabelText.substring (idx, idx+1) +
    “    ” +
    m_strLabelText.substring (idx+1);
    }
    }
    return strLabelText;
    }

    Anyone who is interested in a JSP taglib that offers this (and more accessibility stuff as well). can email me: john (at) lloyd (hyphen) jones (dot) net. Written to use with Struts — source code is available.

  6. I’ve implemented accesskeys on a few sites that we will soon be releasing, but failed to get them working in Opera. I searched their knowledgbase to no avail, and the page that you offered as a link, but nothing – am I overlooking something here?

    If so, can you let us know how to do this in Opera, so that I can put some instructions on our ‘accessibility’ pages?

  7. It is the source I am interested in showing the great people here. I am just used to using ampersand codes to post source code in other forums.

    So, I was not trying to create a live (X)HTML link (and would be suprised if I could), but thank you anyway.

  8. On my website ( http://jessey.net/blog/ ) I use an ORDERED list for primary navigation. I then map the access keys to match the numbers of the ordered list.

    I find displaying the access key itself (underlined, emphasized or whatever) to be rather ugly, so at the moment I just include it in the title attribute of the link itself. This approach is pretty useless in some accessibility scenarios, but it is better than nothing. I will be adding a “help” page soon.

  11. Stuart Robertson wrote:
    > accesskey=”h”>Home

    Its a pity the article doesn’t mention the rather nasty side effects that using access keys has, namly cripling predefined keyboard shortcuts.

    A discussion of the issue was raised on the WAI interest group mailing list:
    http://lists.w3.org/Archives/Public/w3c-wai-ig/2003AprJun/0549.html
    (ensure you read the entire thread though, there is a lot more to it then covered in the initial post)

    Sonia wrote:
    > I’ve implemented accesskeys on a few sites that we will
    > soon be releasing, but failed to get them working in Opera.

    The key combination to use access keys is not dependent on the operating system (as the article claims), its dependant on the browser. Opera uses Shift+Esc, not Alt.

    http://lists.w3.org/Archives/Public/w3c-wai-ig/2003JanMar/0643.html

  12. David,

    Thank you for your response. Those buttons do in fact work in Opera, but it seems that Opera (7.11) doesn’t support numeric accesskeys.

    I’ve tested the keys from the article, which are all letters, and they work fine. I then went to one of my sites, and then to diveintomark.org, and Opera couldn’t ‘fire’ the accesskeys on either of those sites. I have modeled the accesskey use on my sites after that found on diveintomark.org and http://www.webaim.org, among others.

  13. >Its a pity the article doesn’t mention the rather nasty side effects that using >access keys has, namly cripling predefined keyboard shortcuts.

    Depends on the OS (as the article says). On the Mac, you *can’t* over-ride predefined shortcuts defined by the OS. Command+H means “hide this window” in Mac OS X. If you set “H” as your “Home” accesskey shortcut, Command+H won’t load “Home” because that combination is reserved by the OS. But Control+H will work in Mac browsers that support accesskey … for instance it will work in IE5/Mac.

    Maybe Im missing the point but I thought the article got it right.

    The additional info from lists.w3.org is very helpful, though. Thanks!

  14. (Originally presented on the wats.ca web site at: http://wats.ca/resources/accesskeys/19)

    In a non-scientific study conducted in the summer of 2002, we researched the availability of available Accesskeys which had not already been reserved by various other adaptive technologies, such as JAWS (currnetly the most popular Screen Reading application) and IBM’s HomePageReader, a popular screen reading web browser, which has built in keystroke shortcuts for going into different modes:

    Alt + L starts Links reading mode (only read the links on the page)
    Alt + C starts Character reading mode (read character by character)
    Alt + 1 starts Heading reading mode (reading only the headings on a page)
    Alt + O (letter O not number zero) starts Controls reading mode

    HomePageReader makes no distinction between these keystrokes and will not allow you to use accesskeys. Besides, their mechanism actually seems to make more sense — using links mode to cycle through a list of links seems much more useful and usable. (Interestingly, for accesskeys to work in HomePageReader, the user must first “click” the mouse within the display screen of the application… a curious requirement in a tool geared to the visually impaired…)

    Disappointingly, our research discovered that all but 3 keys were previously “claimed” by one technology or the other (including but not limited to the two applications mentioned):

    AccessKey / (slash)
    AccessKey (backslash)
    AccessKey ] (right square bracket)

    At that point it was then pointed out (by Jukka “Yucca” Korpela – a well respected accessibility expert) that even these keys would be inaccessible to users not using a North American Standard (QWERTY) keyboard. So while it seems that Accesskeys is a great idea in principle, implementation brings with it the possibility that it either will not be available to all users, or that the keystroke combination encoded within the web page may conflict with a reserved keystroke combination in an adaptive technology or future user agent.

    This potential problem was subsequently brought to the attention of the Canadian Common Look and Feel Access Working Group (who had previously suggested the standardized use of Accesskeys M, 1 and 2 on Government of Canada web sites), and after consideration the Access Working Group reversed it’s recommendation and now suggest not to use Accesskeys on thier Web sites. (www.cio-dpi.gc.ca/clf-upe/6/skip_e.asp)

  15. A few points about AccessKeys that I haven’t seen addressed often (or well enough)

    First of all, unless I’m daft (which is always possible), there’s no set standard for a site’s access keys. One site might define a ‘home’ link as ‘H’, another may use ‘1’. While each site will have different requirements, it might be valuable for some analysis into standardizing these.

    Your browser’s menu bar also uses ALT + [key] combinations, and a page’s AccessKeys override these. If you’ve managed to hook every menu item’s key into your page as an AccessKey, I can’t really think of a reliable way to get back up to that menu using the keyboard alone. (ie. ALT + F to get to the File menu won’t work if you’re using ‘F’ as an AccessKey)

    JAWS (a popular screenreader) uses its own set of keyboard shortcuts, too, just in case this wasn’t complicated enough. I’ve heard it said the numeric keypad is a popular area, so it’s possible that numbered (AccessKeys 1, 2, 3) navigation will be harder to use than lettered (AccessKeys a, b, c etc.). This is hearsay, but from a source that has a better handle on this than I, so I’m willing to believe it.

  17. AdLad: I didn’t say it always conflicts. 🙂

    I missed the part of the article which mentions the problems for Windows users, but its incomplete.

    On Mozilla for Linux for example, the only way to get at a menu that has a conflicting access key with the keyboard, is to open a different menu, then arrow key to it.

    Even on Windows/IE, while you can get at the menu by pressing alt, releasing it, then pressing the key, there are still two problems.
    (1) The user has to retrain to learn the other method
    (2) Key combos that are consistant everywhere else (other pages, other apps) don’t work! Major violation of the key principle of good interface design – consistancy.

  18. Would there be some way to have accesskey underlining only show up when the user hits or holds down the ALT key, like how windows apps do it? That would be pretty cool, since we wouldn’t have all this ugly underlining all the time, and people wouldn’t have to roll over or focus on the link to find the accesskey (which seems silly – if they’ve already focused on the link or used the mouse to hover it, they can just hit enter or click the mouse – they don’t need an accesskey.)

    It also seems, as some people have already said, that a standard for which accesskeys do what should be established. At least in windows, I know that hitting Alt+F will get me File, and Alt+H will get me help, and F1 will get me the actual help system, so on, no matter what app I’m in. Custom accesskeys for each web page seems pretty useless. The whole point of keyboard shortcuts is that once you get familiar with an app you use the shortcuts – there are not too many people who will be spending so much time on your site that they memorize your accesskeys. It’s like using tags to give navigation hints – it’s a great idea but I haven’t seen any standardization of the keywords so far.

  19. Does anyone know if you Wap or WML support access keys? Would be really useful to assign a number to a link. Would save an awful lot of scrolling in a small screen estate environment.

  21. I do not like the idea of using numbers for Accesskeys (except on smartphones). The reason is that your have a hard time remembering what each number is. It is hard to remember that “4” is e.g. Articles and “5” is Gallery. Also people who use numbers for Accesskeys often use them in the exact same order as you navigation. That presents a potential problem in regards to consistency between sites.

    Instead I like (and use) the idea of fixed Accesskey corresponding to what they do. Like:
    S – Moves focus to the search field
    P – Prints the page (I know that this is also done using CTRL + P, but it would be good practice to implement ALT + P as well – especially when using Accesskey)
    H – Brings you to the home of the current site/section
    etc.

    The good thing about this is that our readers can remember what each key does because the characters correspond to the function.

    One thing I think all of us should read is the OS guidelines for keyboard shortcuts. I think it is important that we mimic the behavior found in the OS. Our readers need consistency and dependability – not only from site to site but also from browser to applications to the OS itself.

    It is of vital importance from a usability perspective.

  22. I’ve actually been doing this for a few months (though I used instead of , for a bit more flexibility), and until reading this I had not realized any of the interaction with the standard accelerators.

    But in testing my navigation menu, I noticed a behavior not mentioned here. In IE/Win, at least, where an attempted access key gets applied depends on where the mouse focus is. By default, it is on the application menu, and the Alt key activates the IE menus. But click down in the content of the Web page, and the IE access keys stop working, and those in your page will (sometimes) start working.

    I have not yet figured out exactly what steps are needed to switch the focus completely with the mouse, but using the tab key seems to do it reliably.

  23. Is there any way to underline the accesskey on a submit buttons? The best way I can think of is by emulating a button using a div with border: 2px solid outset. But then it’s excluded from the tab order – etc – etc. Or a blank button with text absolutely positioned over the top.

  24. You can do this:

    and then in your style sheet:

    button em{
    text-decoration:underline;
    }

  26. Given that the :first doesn’t always work (on the off-chance that you’ve got more than one menu-item that starts with the same letter), and still wanting to keep some separation, I’ve taken to simply adding in what the Accesskey is in the title attribute.
    So your link would be like: blah.

  27. http://www.w3.org/TR/css3-ui/#keyboard

    I did use accesskey’s for some time, but not anymore since i read the CSS3-spec. I think thats a much nicer solution, cause it’s will be hardware independent.

    Together with media-types this will be a powerfull combination to make a document accessible.

    Just my thoughts (o and sorry for my English, i’m from holland you see ;)).

  30. I’ve implemented access keys at my church site:

    http://www.billericaybaptistchurch.freeserve.co.uk/

    and see also:

    http://www.billericaybaptistchurch.freeserve.co.uk/accessibility.html

    I haven’t found a problem with “overloading” already-defined shortcuts on IE or Mozilla: it seems that if the web page itself has the focus, the access keys I define get priority.

    I’ve also found that using display: none; on an accesskey link prevents it from working, so for keys that don’t have a corresponding visible link, I’ve had to include the light-grey “access bar” in the footer.

    Thoughts? Does this work well?

  31. The problem is that browser implement something like typeahead (mozilla, …) find have problems with accesskeys… or better typeahead find gets prio over access keys. Have anybody a solution for this?

  33. PRIORITY VERY LOW:

    Matthias said:
    >Just some historical information. The article says “So can your site, thanks to the XHTML accesskey attribute.” But this is not unique for XHTML, the attribute was already available in HTML 4: http://www.w3.org/TR/html4/interact/forms.html#adef-accesskey

    Matthias:

    We know that. But if our little intro paragraph had said, “So can your site, thanks to the HTML accesskey attribute,” some readers would write in: “Why are you promoting HTML? HTML is outdated! You should be promoting XHTML.”

    Know what I’m sayin’. Some of our readers are like that.

    Mainly, although accesskey is in both XHTML and HTML, I chose to use XHTML as the representative markup language because it is the current standard and has benefits HTML lacks. Not to make too big a deal of this small point.

  34. The browser listed under heading …Denied are preceded by this
    ”
    The accesskey attribute is currently supported by the following web browsers:”

    Should this be changed to “is currently NOT supported..

  35. only scanned the forum, but assuming this were actually supported, you could set any link with an access key to display its accesskey. no need to be specific to its location. so menus, submenus, and anything else is covered.

    a[accesskey]:after
    content: ” [” attr(accesskey) “] “;
    }

  37. Galeon does support these access keys. It works fine in Galeon 1.3.5 that I am using presently. The problem I see with them is that the platform gets in the way. On my machine practically every alt- and ctrl- combination is already spoken for. So if you have an accesskey alt-h, that won’t work for me because alt-h invokes the help menu. alt-p works, however. ctrl-everything is completely out of the question.

    Inconsistency is a killer.

  39. Joel Goldstick wrote:
    >The browser listed under heading …Denied are preceded by this
    “The accesskey attribute is currently supported by the following web browsers:”

    >Should this be changed to “is currently NOT supported..

    No. The statement is correct. The browsers listed first support accesskey. Those listed next (such as Safari) do not support accesskey.

    I can see how the subhead, “Accesskey Denied,” could set up the wrong expectation, though. The subhead title preceded the writing of that section, and in hindsight it doesn’t track as smoothly as it might. “Accesskey support in browsers: good news, bad news” might have worked better, for instance.

  40. Thomas Baekdal wrote:
    >Instead I like (and use) the idea of fixed Accesskey corresponding to >what they do. Like:
    >S – Moves focus to the search field
    >P – Prints the page (I know that this is also done using CTRL + P, but it >would be good practice to implement ALT + P as well – especially when >using Accesskey)
    >H – Brings you to the home of the current site/section
    >etc.

    you forgot that there are a lot more languages than english. in german “search” for example could be translated “finden”. how do you want to highlight the “s” in it, if there is none?

  41. Another kind of people Accesskeys will be very useful for are RSI (Repetitive Strain Injury) sufferers like myself. More and more people in the “web-world” are developing RSI (because of prolonged and inadequate computer use), which, even if it is not totally crippling, tends to make one throw the mouse out of the window.

    The number of speech recognition software (Dragon, ViaVoice) users is increasing and will continue to do so (RSI and other factors) — and it is /much/ easier to mimic keystrokes than mouse mouvements by voice. Everything that can be done with the keyboard can be done by voice. Not everything done with the mouse can — without being clumsy.

    So… just another group of people who will benefit from Accesskeys — and maybe a group which is closer to the web design community (to some extent, part of it!)

  42. Let’s not forget that a very good way of alerting users to available accesskeys and any other accessibility features is to include an Accessibility Statement on your sites, with a link to it from each and every page. I usually tuck the link in to the footer, with the copyright and terms of use links. Example: http://www.eu-employment-observatory.net/

  43. …it goes without saying that the link to the accessibility statement is assigned an accesskey…

  44. No-one seems to have mentioned that if you use SPANs inside a link to indicate an underlined letter then IBM homepagereader interprets this as a pause. Thus instead of ‘Home’ you hear ‘H’ – ‘ome’ – hardly intuitive.

    tags don’t cause a pause but are deprecated, thus failing validation. I’m not sure if produces a pause, but then if you’re using good markup then you’d only use an where you thought there should be emphasis – possibly in this case?

    I think I’ve tried every method listed in the article in the past, and the only solution I’ve found that didn’t break accessibility for one group or another, or fail w3 validation is providing an accessibility layout/stylesheet that displays the access key in brackets after the link (using content(attr) in gecko and a JS workaround in IE). If every page on the site has an option to change to that style and a link to an accessibility page explaining the features hopefully anyone arriving at the site and experiencing problems would try those options first.

    Along with a script to disable all accesskeys for users fo assistive software that conflicts (assuming script support of course) this covers most bases.

    The only other point on this topic that bugs me are the automated accessiblity testers (B*bby, C*nthia etc), failing pages for ‘not including access key attributes for all links’ – the spec says ‘important links’ making this check at least a manual one.

    ==end rant 😉

  45. I spent a few minutes checking out digitallife (http://www.radionz.co.nz/digitallife/index.html) so I could see how the access keys performed. In Netscape 7, they work very well. When I type the key combinations, the link is triggered. But in IE6/Winxp it really sucks. I realize that this was mentioned in the article, but I think it’s worth pointing out again: In IE you have to press enter after typing the access key. In addition, it then works inconsistently and there really isn’t any way to know what link you’re triggering. Since about 95% of our users are on IE (at least where I work) it doesn’t seem worth it. In fact, I think it would just annoy people who try to figure it out.

  46. David wrote:

    “The accesskeys specified in the Guidelines for UK Government websites are recieving fairly heavy adoption …”

    They’ve actually disappeared off the main English Heritage site recently. However, there is a rather ugly “accessible site”, a sort of “ghetto-site” linked to from the main site. They are used there. I guess it does the job – it nearly validates, too (I’m assuming iso-8859-1) – which is quite a shock:

    http://accessibility.english-heritage.org.uk/

  48. If you remove the need to press “ENTER” after using an accesskey by adding onfocus=”location.href(this.href); return false;” to each link, then the users will be unable to use the back button. If they try to go back, it acts as if they just clicked on the link! They could of course just not use the back button.

    However for bookmarklets it is unavoidably annoying becuase bookmarklets always return void and thus you always leave the user in a perpetual loop.

  49. So now there are two reasons why “onfocus=”location.href(this.href); return false;” on links are only a half solution; does anybody have an alternate solution for IE users? please? 🙂

  50. The problem with accesskey is that due to the way they are implemented across browsers, there is no reportoire of access keys that will work reliably. If we limit limit ourselves to the English locale versions of Opera, Mozilla and MSIE, the only access keys that will work is i, m, n, o and w. No, the numbers won’t work, and all the other access keys interfere with normal operation of the browser.

    I’ve done a detailed writeup on this at http://www.virtuelvis.com/archives/86.html – with a proposed replacement mechanism for future xhtml dialects.

  52. Many Windows users with disabilities that limit their use of the keyboard and mouse will navigate using the StickyKeys utility. It “holds down” the control keys with a single press so that shortcut combinations can be typed with one finger (or a pencil or mouthstick, etc.).

    The article points out that accesskeys override Internet Explorer’s predefined shortcuts and suggests that they can still be used by pressing the ALT key first and then pressing the shortcut character.

    If you’re using StickyKeys, pressing the ALT key first has the same effect as holding it down while pressing the shortcut character, so you still can’t activate the predefined shortcut.

    StickyKey users can access some predefined shortcuts by pressing F10 (instead of ALT) before pressing the shortcut character. Unfortunately this method is probably known only to more experienced users and only works for selecting menu items (F10 followed by F selects the File menu).

    For example, F10 followed by D will not activate the shortcut to highlight text in the Address bar if the site uses D as an accesskey.

  53. Hello everyone.
    I have a little painful question.
    We all know thtat if link a page by a wonderful:
    Widgets

    That page will be relevant to the “widgets” keyword.
    Ok?
    So, if I am a good webmaster and i want to hadd accesskeys to my link i got to code:

    Widgets

    Ok? Will breaking up the linking word by means of the little tag affect the page’s relevance for the keyword “widgets”?

  54. Having read the article, I tried to implement the recommendations and came across a couple of problems.

    First one is perhaps too obvious – the first-letter technique will only work if the menu items all start with a different letter which I would think is very rare.

    Second – it may be just me but the point of accesskeys is to navigate through the site without using the mouse or having to tab through each item. This make the :hover and :focus selective display idea seem a bit pointless. Regular users would eventually learn the accesskeys but it would be simpler if they could see them all the time (which would make the stylesheet switcher at better compromise).

    For simplicity I have implemented the technique and am now wondering how I can aid screen readers. Do blind users find accesskeys useful? If so, what is the best way to help them find and remember each key?

  55. Although access keys have some short comings I still found this article very useful. I have known about access keys for sometime, but because of shaky browser support in the past have never used them before.

    I am now trying them on my personal site, I have underlined key letters on the menus and made a small icon informing visitors my site uses access keys.

    Although my site is far from being completely accessible, I see access keys as at least helping make things a little easier for mobilty impaired users. Once again, a very useful article!

  56. Thomas,

    You have significantly *decreased* accessibility to your intranet by auto-activating links on focus. How is a keyboard user meant to tab through the page now?

  57. One thing I didn’t notice in the article, which otherwise mentions browser support, is that the :before and :after pseudos are only supported in Mozilla and Opera – no support in IE. Had me excited there for a few minutes, but sadly, browser standards support disappoints again.

  58. Opera 7 has got a great feature called Spatial Navigation. By using Shift-arrow one can hop from one navigational element to the other – across layers, table cell borders and even frame borders. It’s really intuitive.

    IMHO this solution is much better than using accesskeys, which tend to require a lot of explanation. Users that appreciate accessibility should get a browser that enables it 😉

  59. I am using IE6… does anyone else have the menu example pop to the left on mouseover? This did not happen in Mozilla.

    Thanks,
    Jim S.

  61. Hmm. I should have read the text at the top of the page. 😉

    “Welcome to the ALA forum. HTML displays but does not render. To create a live link, simply type the URL. “

  62. No one has really discussed how to use accesskeys with form buttons. When these are used the action of the button (submit, javascript onfocus, etc.) kick off automatically. Which is okay as long as the user knows that. However, if you use input buttons you can not em/underline the name= parameter in the input element.

    Or does anyone have a work around for this?

  63. We are very concerned about accessibility on our Web site and I am interested in studying further about this. Thank you for the article.

    A comment re: Zociety Magazine

    I would recommend against activating the link on focus, as that means people can no longer tab through links if that is what they would prefer to do.

    The question is, what happens (using the first-letter scheme) if two menu items begin with the same letter? I’d guess only one of them will work.

    Also, we have decided for accessibility reasons that nearly all links on our site (except for a few buttons) shall be completely underlined, so that people who are not internet savvy do not have to figure out that a link is a link. Is there a way to double-underline the accesskey shortcuts?

  64. In the past, I purposely did not implement access keys because I didn’t like the idea of my access keys overriding a browser or operating system’s own shortcuts. I’ve since reconsidered and have struck this compromise – on pages with the main navigation at the page top, I have one access key that goes to the page top. I like this idea, and it reduces the need for “go to top” links on long pages. For an example, on the http://www.grandblancchamber.com/directory/members.asp page, there is a box that explains the access key shortcut because this is such a long page.

    At http://www.grandblancchamber.com every page has a link to Site Usage Tips, which explains how to use the access key of 1. After I set that up, I learned that numbers do not work in Opera and Alt+1 conflicts with the faily popular headings reading mode in JAWS.

    At http://www.suskiwebdesign.com, I use the letter n instead (warning, tutorials section of site needs lots of work). Now Opera is included, and I haven’t found any big time conflicts. “N” for navigation seems easy enough to remember.

    Any feedback to this idea is more than welcome. Building accessible websites is such a balancing act!

  65. Yes you can format buttons, including text within buttons. The “trick” is to not use but instead use something like . See my site (www.GeorgeHernandez.com) for a working example of this.

    PS1: I didn’t use accesskey for HTML until this article because when I tried it out years ago it didn’t seem to work. It probably did work (i.e. it put focus on the link) but I didn’t do the next step of pressing ENTER. Doh!

    PS2: I tried to use ALT+D for Dictionary.com but through use I found that I definitely prefer to use ALT+D to get to the address bar, so bye-bye Dictionary.com 🙁 .

  66. Thomas Baekdal (et al.)

    There’s a better, more transparent way (and certainly less time consuming) to make accesskey links in IE auto-link with focus.

    First of all, your approach has a fundamental flaw. What if the the user simply doesn’t have a mouse (or is not using it) and begins to tab through the document. OOPS! they get linked to the first one they focus on. Hardly a desirable result. Instead, the process should be make to trip only when the ALT key is pressed congruently with a focus trigger.

    Now, since we only want this for IE, we can use a DHTML behavior to trasparently and easily add this functionality to our links. First, add this to your css

    a { behavior: url(misc.htc) }

    Then, create the HTC file

    That’s it! You don’t have to touch the HTML of EVERY SINGLE link.

  67. yes you can format form buttons using the syntax George Henandex describes. Unfortunately at least some verisons of IE/Win submit the text of the button instead of the value. 🙁

    e.g. “Submit” instead of “Submit”

  68. Peter,

    Thank you, that is indeed a better way – and I did have a problem when people used TAB to navigate the document. In most cases we ‘solve’ the problem by applying tabindex=”-1″, but that presents another problem.

    Now, I feel somewhat foolish since I use the HTC behavior in other parts of the system (for something else)…

    Again, thank you!

  69. I have Opera 7.11 and tried ALT+accesskey
    However Opera opens its own menus and don’t support access key feature!

  70. I implemented the onfocus=”location.href(this.href); return false;” suggestion by Thomas Baekdal. Yes, it did eliminate hitting the enter key in IE 5.5 (Win95) and IE6 (Win2K). Unfortunately, using the back button of the browser to return to the page with the accesskey caused that page to immediately redirect back to the page that the accesskey points to. A rather odd behavior which does not happen in Netscape, but then, Netscape didn’t need it in the first palce.

  72. Having read the article and all the comments posted so far, I have a few of my own.
    1. Thanks Harold, for your info about iCab. This means that I do have a browser which supports access keys although it is one of those which requires that focus is somewhere within the page before it works. Shame the rendering engine is so disappointing.
    2. I have 10 other browsers residing on my OS9.1 iMac’s hard drive (I’m a hobbyist web designer) on none of which I can persuade access keys to work including the 3 versions of IE5/Mac which the article claims to be supportive, Apartness.
    3. The feeling that almost overwhelms when reading the comments is that this system is too flawed to be useful and maybe it’s best to wait for a better one to emerge such as CSS3 mentioned by Anne.
    4. Finally, I am going to follow the advice of the Canadian access group cited by John Foliot and not use access keys. Instead, I shall continue with a system based on correct structural markup and a logical tabbing order.

  73. http://www.alistapart.com/stories/accesskeys/discuss/3/#ala-1993
    “on pages with the main navigation at the page top, I have one access key that goes to the page top”

    Keyboards have a Key for that. “Pos1” is probably the better solution (works on _every_ site and evey PC supports it)

    The main navigation is probably better done with standard tags in the of the page.

    http://www.w3.org/TR/html4/types.html#type-links
    Browsers can assign consistent shortcuts (or speech commands, pen gestures, whatever) to these elements which makes them _much_ more accessible.

  74. “on pages with the main navigation at the page top, I have one access key that goes to the page top”

    “Keyboards have a Key for that. “Pos1″ is probably the better solution (works on _every_ site and evey PC supports it)”

    Thanks for your idea – I should probably know this, but can you explain further what you mean by “Pos1”? I am aware that pressing the Home key always goes to the page’s top, and there is a PgUp key also. The reason I don’t rely on these is that if a user is tabbing through links on a page, pressing the Home key does not change the focus of the links. This means that even though the screen shows that you are at the top of the page after pressing the Home key, the next time you press the tab key to go to the next link, it won’t be to the navigation bar (using the layout of the interior pages on my personal site as an example), but to the next link from where your tabbing left off.

    “The main navigation is probably better done with standard tags in the of the page.”

    I like this, too, and have recently started implementing this in addition to having one access key that goes up to the main navigation. Opera does a great job of making this obvious to users.

  76. reply to:
    http://www.alistapart.com/stories/accesskeys/discuss/3/#ala-2012

    “what you mean by “Pos1″? I am aware that pressing the Home key always goes to the page’s top”

    I have a german keyboard so “home” and “pos1” seem to be the same key.

    “…top of the page after pressing the Home key, the next time you press the tab key to go to the next link, it won’t be to the navigation bar”

    Oh, I wasn’t aware of that. Opera does not do this. (but IE/Win and Mozilla 1.3/Win)

  77. It is easier to find links if they are underlined. So, what would be a good way to emphasize shortcut keys on a site that underlines links?

  78. This is just plain stupid. There are no accessibility tweaks one has to apply to word processing documents, e-mail, or spreadsheets. Those are documents. HTML is used to create documents.

    Why bother trying to solve something that is a problem to be solved by the rendering software? This is not our problem to solve in any way, shape, or form.

    There are menus in browsers. There are tab functions that browsers support. There are screen readers and magnifiers. There are screen readers. Enough, already!

    It is with articles such as this one that the zeal for accessibility brings out the zealots.

  79. Just read the article and I am going to implement this on my site.

    Have decided after reading this forum not to use (as far as possible) the following letters as they are used in the top menu of browsers (IE, Netscape, Mozilla, Opera) “F,E,V,A,T,H,G,B,W,N,M” This means that I should not disable browser defined accesskeys too much. I know there are others but at least it will not disable the main menu.

    My next problem is that my sub menus are dynamically generated from a database, so I need to work out a way to dynamically generate the accesskeys ensuring there are no duplicates on the page (I feel a headache coming on)

  80. ive recently been banned from google for having ‘hidden’ content. my question is this. If google bans sites that validly hide content for accessability reasons then what should i do?

    there are a number of tricks that i believe are commonly used in accessible design e.g. using a h1 tag containing a text header where the text is hidden and the h1 contains a background image resulting in text based browsers seeing a text title and gfx based browsers getting some eyecandy…

    ..i know you’re all going to say something like ‘just stick to the standards’ but im getting a little tired of the standard 2/3 column xhtml blog style sites that are poping up…

    mark

  81. I tried to use accesskeys in MIDAS forms:


    But it doesn’t work! I mean the MIDAS iframe doesn’t get focus (both in Mozilla and IE)
    Does anyone know how to solve such problem?

  83. I’ve been experimenting with accessibility options on my site at http://www.pdrummond.btinternet.co.uk/
    There is an option to show/hide the access key shortcuts for the main navigation links. It works perfectly in Mozilla, but not in Internet Explorer. Safari displays the access keys, but only when the mouse rolls over. (This bug has been spotted according to David Hyatt).
    If anyone can tell me why the text size option doesn’t work I’d appreciate it.

  84. A lot of posts here so sorry if i have repeated that of someone else. In the Uk the Government have adopted a policy of using access keys on their pages and have given directions and instructions of which keys to use so that all Government departments stick to the same set of rules enabling a user of these sites standardization. Therefore when a user visits a Government department’s website for the first time they bring their collective experience gained from all other sites. More information on Accesskeys can be found here,
    http://www.e-envoy.gov.uk/
    Click on the site map and then follow the information for webmasters.

  86. In Galeon 2 (1.3, actually), with Gecko from Mozilla 1.4, access keys work: however, the application keys take priority — therefore, alt-e doesn’t work. Alt-o, does, et cetera.

  87. I keep my carpal tunnels comparatively happy with reduced mousing and lots of keyboard work. I *love* Accesskeys, even when (though) they’re flawed.

    For me on IE5.5, having to press [enter] to get to the Accesskeyed link is a feature, not a bug. I don’t want to find myself at a new page without having made the decision to go there, equivalent to the mouse-click.

    I support Gareth Plevin’s decision:

    Have decided after reading this forum not to use (as far as possible) the following letters as they are used in the top menu of browsers (IE, Netscape, Mozilla, Opera) “F,E,V,A,T,H,G,B,W,N,M” This means that I should not disable browser defined accesskeys too much. I know there are others but at least it will not disable the main menu.

    This is *really important*, because we keyboarders use the keyboard shortcuts to the main menu reflexively. If you make us stop and think about what “Alt-V” means, we will become slow and thus cranky. The slowness is particularly aggravating because keyboard shortcuts are *faster* than those damn mice you-all are using, especially when we’re touch typists.

    You “normal” guys may think Accesskeys are catering to my limitations, but (properly done) they could also be a way of speeding up *your* surfing, too.

  89. Whatever you do, don’t mess with my ALT+{arrow} options – I use them to go forward, backward, up and down. The last thing I need is some nimrod webmaster thinking it would be cool to put ALT+Back Arrow to take me to the homepage.

    Please don’t screw this up.

  90. As another keyboarder, I *love* access-keys too, flaws and all. Access-keys being overridden by the OS or the Browser is absolutely fine, and the way it should be. The other way round is, of course, a bad thing.

    The best accessibility should be additive, not subtractive. It doesn’t matter if the browser can’t implement a feature, so long as the feature doesn’t disable the browser. So keep those access-keys coming for a while yet.

    I would suggest that we stick to numerics. They have their disadvantages, but fewer than most alphabetics. As far as I can remember, you can’t override browser commands with numeric access-keys in any browser or screen-reader. IBM HomePage Readers may be able to put me right on this, but I’m fairly sure that is correct.

    Don’t forget to put rels in too 🙂

  91. hey Simon, instead of underlining or bolding the accesskey queue play with the value of the letter. Or you could mess with its opacity, or hue, or …something else that isn’t so techy/clumsy as adding typographic junk. Although underlining a letter is pretty much the same typographically as underlining a link in a paragraph (ugly but it works). Pretty soon I’m going to need more buttons and meta keys on my mouse and keyboard if this trend keeps up. Looking forward to the day when all the chrome disappears and the menus appear on the rendered-web-page (out of nowhere) based on key+mouse input.

  92. I think the only sensible way of using access keys is to use a defined standard.

    At the moment I am in the process of pushing through a redsign of a local government web site (nothing live from the redesign, so no link :p). We have settled on the UK e-government standard for access keys. The more widespread these become, the easier it will be for users to remember which keys are available, and what those keys always link to.

    All we then need to do is to indicate that their use is available, and to provide a list for those who need to know. The UK e-gov standard defines the following access keys:

    S – Skip navigation
    1 – Home page
    2 – What’s new
    3 – Site map
    4 – Search
    5 – Frequently Asked Questions (FAQ)
    6 – Help
    7 – Complaints procedure
    8 – Terms and conditions
    9 – Feedback form
    0 – Access key details

    I beleive that non-standard access keys have little use as they will be different across different sites, thus adding very little to the user experience.

  93. Hey I keep trying to validate as AAA at BOOBY… 508 no prob, but using javascript to force IE to pretend to be compliant… that seems to me that it will cause the page to fail AAA validation… help me out here 🙂

    Here is what I am working on not done but in the pipe for the 10th time 🙂
    http://tentonweb.com/2003b/

    Jim S.

  94. I tried using Peter’s example but it isn’t working for me. Explorer still requires the Enter key. I know very little about DHTML behaviors…do I have to do anything not mentioned in his explanation to make it work?

  96. Someone asked about the possibility of double underlining the access-keys and thus leaving the link underlined:

    solution one – puts the doubled line over the main underline

    a { text-decoration: none; border-bottom-style: solid; border-bottom-width: 1px; padding: 1px; }
    a em { font-style: normal; font-weight: normal; text-decoration: underline; }

    solution 2 – puts the doubled line under the main underline:

    a em { font-style: normal; font-weight: normal; border-bottom-style: solid; border-bottom-width: 1px;}

  97. I’ve recently discovered the label tag. It allows you to connect text labels to form elements. The label also carries an accesskey attribute which focuses the control to the form element specified by the for attribute. It’s way cool in this context.

  98. unless there is standard like what we have in desktop application (Alt-f for file and so on), I don’t see the necessity to have it. Users who have difficulty moving the conventional mouse, they would likely to have difficulty pressing ALT and the letter. They’d be better off getting a track ball mouse. what do you think?

  100. I think you have /no/ clue what you’re talking about.

    Ever used a speach input program? Depending on the quality of the program (especially one designed for the handicapped) it’s usually fairly easy to input a keycombo, without moving anything but your jaw.

    Stickykeys (which was mentioned earlier in the thread) can be used by a user who types with a mouthstick or a single finger to press the two keys as seperate motions. The mouthstick user could not /possiblly/ use a trackball, and though the user with a single working finger /might/ be able to use it it would be signifigantly more difficult than the keyboard.

  101. Hello all, never knew there was a forum here so I’ll copy a post I just made in another forum. :), I hope someone here can help.

    Hello all once again.
    Ok, I have been playing about with css and looking around many different sites till I found an article from ‘a list apart’: Click here to view

    So, Here is the page I want two be able to change: click here

    I have this in the Head :

    quote:
    ——————————————————————————–
    ——————————————————————————–

    and these are the links in the page:

    quote:
    ——————————————————————————–
    change style to default

    change style to red
    ——————————————————————————–

    The .js files contains this:
    function setActiveStyleSheet(title) {
    var i, a, main;
    for(i=0; (a = document.getElementsByTagName(“link”)[i]); i++) {
    if(a.getAttribute(“rel”).indexOf(“style”) != -1 && a.getAttribute(“title”)) {
    a.disabled = true;
    if(a.getAttribute(“title”) == title) a.disabled = false;
    }
    }
    }

    function getActiveStyleSheet() {
    var i, a;
    for(i=0; (a = document.getElementsByTagName(“link”)[i]); i++) {
    if(a.getAttribute(“rel”).indexOf(“style”) != -1 && a.getAttribute(“title”) && !a.disabled) return a.getAttribute(“title”);
    }
    return null;
    }

    function getPreferredStyleSheet() {
    var i, a;
    for(i=0; (a = document.getElementsByTagName(“link”)[i]); i++) {
    if(a.getAttribute(“rel”).indexOf(“style”) != -1
    && a.getAttribute(“rel”).indexOf(“alt”) == -1
    && a.getAttribute(“title”)
    ) return a.getAttribute(“title”);
    }
    return null;
    }

    function createCookie(name,value,days) {
    if (days) {
    var date = new Date();
    date.setTime(date.getTime()+(days*24*60*60*1000));
    var expires = “; expires=”+date.toGMTString();
    }
    else expires = “”;
    document.ignore = name+”=”+value+expires+”; path=/”;
    }

    function readCookie(name) {
    var nameEQ = name + “=”;
    var ca = document.cookie.split(‘;’);
    for(var i=0;i < ca.length;i++) { var c = ca[i]; while (c.charAt(0)==' ') c = c.substring(1,c.length); if (c.indexOf(nameEQ) == 0) return c.substring(nameEQ.length,c.length); } return null; } window.onload = function(e) { var cookie = readCookie("style"); var title = cookie ? cookie : getPreferredStyleSheet(); setActiveStyleSheet(title); } window.onunload = function(e) { var title = getActiveStyleSheet(); createCookie("style", title, 365); } var cookie = readCookie("style"); var title = cookie ? cookie : getPreferredStyleSheet(); setActiveStyleSheet(title);[/QUOTE] So I have it all uploaded but when I try to change to the red theme nothing happens and when I try to open the .js file I get an error. Can someone plz help Once again: click here to see the page I am working on. Thank you

  103. As well as pressing and releasing Alt to activate the Windows menu bar, the following also works in both Windows 95/98/XP AND Linux/Unix (I haven’t checked Macx recently)

    Just press the F10 function key, and the file menu will be highlighted…

    And to answer somebody above, Yes, Wap/WML does support accesskeys, where they are actually much more important considering many people will be using a mobile phone!

    Anyway, I fully support the numerical scheme as suggested by the UK government. You can’t go far wrong with numbers, and I can only hope that this becomes an international standard on every site. After all, Ctrl+C is ALWAYS copy in every application, isn’t it?

  108. If you are on a web page with, for example, the accesskey F it usually (IE NS Moz I’ve tried- but I have no Mac) is no problem to chose whether you want the file menu: Press and RELEASE [Alt] then [F]-viola you have file menu, or the accesskey: Press and HOLD [Alt] and press [F] you get the page element connected to F. Works fine.

    There can be some problems if you have frames. Ctrl + Tab can change the focus so you get to the right frame. It can also be a way to activate the page (w its accesskeys) without having to “click” in the page.

    Having info about accesskeys in title for a link can be useful if it is a common link that the persoen may use again later. (Otherwise it is rather unnnecessary since you already have the mouse there when you see the title).

  109. My experience (IE NS Moz on Windows) has been that there is no big problem with browser shortcuts and acceskeys. For example if I have a page with an accesskey F going to link “Fun and Games” but I want to open the File menu. In that case I press and RELEASE [Alt] and then press [F] and get the File menu. If I want the acceskey I press and HOLD the [Alt] and press [F].

    I like the IE variant with [Enter] to confirm, which makes it possible to handle situations with a) two or more identical accesskey on a page with sevaral frames b) actually wanting to jump to a link next to one with an accesskey.

    Another problem can be choosing which frame I want to be in. Ctrl + Tab can change the focus. I believe this can also solve the problem of not reaching the accesskey before “mouse click”ing on the page, which is not very consistent with keyboard steering.

    I would like to warn against schemes that just can mark the first character. If several choices have the same first letter, it should be easy to choose another.

    Since I prefer underlined links to “hard to find” ones I was happy to find that “overline” with stylesheet gave a (rather) familar marking way that was compatible with “classic” underlined links. (Interesting that Linux Konqueror browser didn’t underline the overlined character in an underlined link, tho IE NS did both. No problem tho.)

  110. Why don’t people just use this type of Java Script to make one-touch hotkeys? I am not sure if they work on all or even many browsers, but they work well in IE.

    ——————————-


    This site equipped with Key Launcher!

The following launcher keys are available:

Press the letter 'h' for: Home Page
Press the letter 'f' for: Feedback Page
Press the letter 'n' for: What's New Page
Press the letter 's' for: Site Contents


    Free JavaScripts provided
    by The JavaScript Source

    ———————————

    This is puplished with a working demo at
    http://javascript.internet.com/navigation/key-launcher.html

  111. http://javascript.internet.com/navigation/key-launcher.html

    has a working Java Script that allows one-key hotkeys. Look Ma, NO ALT KEY! I have modified a version of this to launch both scripts ( many based on my favorite bookmarklets such as a CSS file switcher ) an links ( such as the link to the index, help page, or NEXT page in a browsable catalog. ) IS anyone interested in such a .js file? Post here if you are. I will past my site’S URL if interest is demonstred here.

    my e-mail account is winjapan on y*hoo.com

  112. Does anyone use, like, or distrust the Java Script found on
    http://javascript.internet.com/navigation/key-launcher.html
    that launches links at the touch of a single key? This does not require Alt or Control keys! With modification, I use it to launch Java Script functions at the touch of single keys. Imagine running a bookmarklet for your user when she types a single keystroke! I have used this to toggle table grid css files on and off for debugging in the design stage of my site. I also use it for zoom and NEXT/BACK keys in an on-line catalog containing a series of pages. KNow a better script or method to do this? Let everyone know. Let me know.

    Post comments here or write to me at winjapan on my com.yahoo account. (reversed to block spam)

  114. Access keys are only valuable if there is a standard set across applications or if the same user frequents your site/application very often and has time to learn your accesskeys. Users don’t want to think about learning how to use your site, they just want to use it, and quickly. I develop web and windows applications and the majority of my daily users stick with the mouse even when accesskeys are available. Even after training only a very small percentage start using accesskeys, and then they only use the common ones they remember. They typically don’t search out any other accesskeys to use, that takes time and energy. Unless the user has a true need, such as a disability or repetative tasks, accesskeys will rarely be used by most of your users. As a develper, you perform the same repetative tasks day after day and quickly adapt to accesskeys to speed things up. Don’t make the mistake of comparing your skills and needs of those of the average user.

  115. In one of the websites we built, we used the First letter approach to indicate the accesskey, just as your first suggestion. The only disadvantage you mention is that this requires you to add to all your accesskeys.

    I have found another major disadvantage: some speech browsers will mispronounce the word, splitting it into two: “F” “irst”. Especially when indicating an accesskey that is _not_ the first key, this can be very co n fusing (if you see what I mean).

  116. Gareth Plevin wrote you shouldn’t use “F,E,V,A,T,H,G,B,W,N,M” as accesskeys since these are used in standard browsers to access the menus. I totally agree with him on that point.

    I want to point out however, that I don’t know what language my visitor’s browser uses. I’m Dutch myself, and most people here use a Dutch operating system where the File menu is called “Bestand” with accesskey B. This means in a Dutch Internet Explorer, you get a completely different set of accesskeys to exclude.

    Since I cannot predict what language the browser of my visitor is in, I cannot predict what letters will already be in use. And that’s just the browser. Who knows what other tools or assistive technology users have installed and attached accesskeys to which will be hijacked by accesskeys defined in a page…

    Unless and until user agents will disallow overwriting of the browsers accesskeys (or make this an option), I think it’s safer to stick to numerical accesskeys…

  117. As mentioned earlier: why not using W3C’s HTML4-defined Link-types more often?

    Why can’t they make the function-keys available for using with accesskeys?

  118. it seems to me tab is a better way to go for easy link access than access keys. unless you have a ton of links. access keys are limited too right? what happens if you have more than 100 links and wish to use access keys for all?

  120. On an intranet-wep-application I wrote the accesskey-feature were only added in release 2 and not surprisingly: The user-experience increased quite a lot on release 2.

    On feature I like very much is to underline the letter of the accesskey, but my application uses buttons to submit web-forms.

    Up until now I haven’t been able to figure out a way to underline one letter of the text of a button. For now I add (x) behind the text on the button.

    I still have to look in to the full CSS2-specs if it’s possible, but if someone has any suggestion, ……

  122. DiveIntoAccessibility.org suggests using some common access keys. By standardizing on a few, it’s easier to find the rest. They suggest:
    Access Key 1 = Home page
    Access Key 2 = Skip navigation link
    Access Key 9 = Contact us form
    Access Key 0 = Accessibility statement where, among other things, you can describe the rest of the access keys.
    Another link that suggests standardizing on some common access keys: http://www.cs.tut.fi/~jkorpela/forms/accesskey.html

  123. This prototype usage of one-touch access keys links next and back to the present page.
    (+, -)

    For me, the developer, it can call report making scripts to list
    1. estimated download time.(q)
    2. images and alt properies.(m)
    3. all link href values. (l)

    I can also zoom the page of main gif. (i, o)

    Text is Japanese
    – look in html code for list of hotkeys in English.

    What are people’s thoughts on this? It does not seem to interfere with Alt-F of Alt-E. IT DOES not make any sense to use on any page with an input textbox since input becomes impossible. THE JS file will be updated and reanemed… so do not link your site to it, folks! If anyone would like to use the JS file, please write to me at my yahoo.com address about it. If anyone can better the table functions, write me and we shall post or permanently host them FOR MOR DEVELOPERS TO USE!
    –Walter-

  125. This was a terrible article, but what do you expect from ALA? This is a typical Javascript job. Using CSS for behaviour is very stupid. This is going on my website on Friday.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA