Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

I'm Still Off Accesskeys

January 04, 2005

A follow-up to last year’s article that denounced Accesskeys.

Just over a year ago I wrote that I believed Accesskeys to be more harmful than good, supported by three articles from WATS (Is it Worth it?, More Reasons…, Accesskey Alternatives) and my own personal experience.

Since then, I’ve decided that while there may be no explicit accessibility benefits, perhaps Accesskeys offer something for usability. Keyboard shortcuts, for those that know how to use them, can be a tremendous incremental time-saver.

I re-enabled Accesskeys on this site a few months back, following Richard Rutter’s research into Accesskey Standards. The idea was to provide quick ways of accessing common site functionality for those that are aware of them, while hopefully preventing any conflicts with existing shortcuts built in to browsers.

The verdict? I never use them, and I’ve received a grand total of one email about them in that time. Discoverability is yet another problem with relying on Accesskeys, but I had hoped that, at the very least, my contradictory position would have prompted a bit of discussion with the odd reader who happened to view source. No such luck.

Nothing new here, so if you’re going out of your way to implement Accesskeys? Don’t bother. I’m not in a hurry to take them out since they’re not hurting anyone (as far as I know), but I won’t be implementing them in future work.

Update: I should clarify I had web sites in mind as I wrote this, not web applications. For those who have commented that web applications are a special case and, be it through Accesskeys or custom Javascript that hooks into keyboard events or whatever else, some form of shortcut key interaction is a good thing for usability — I agree.

However, I also think that as the practice takes off, it will become necessary to do some serious testing to make sure that they help usability more than they hinder accessibility. The question of self-containedness is the issue, and how unlike a web browser you’re trying to make a web browser act.

As an application becomes its own little island of individual interaction standards, it’s not unreasonable to expect more leeway from a user’s default setup. But there will be some fun conflicts between those who expect the user/browser is in control, and those who expect the application is in control — look at the font size issue for a minor version of what’s to come.

Jim says:
January 04, 01h

I made a habit of using AK+1 for the first field of the first form on a page, AK+2 for the first field of the second form on a page, and so on.

The reason being that letters generally conflict with menu options etc.

Then Firefox promptly added AK+1 for the first tab, AK+2 for the second tab, and so on, making all my accesskeys pretty useless.

I was already fed up with the Firefox developers for switching right-click+T from a useful, consistent shortcut for opening a bookmark in a new tab, to a destructive action (good luck getting your bookmarks back when you’ve tried opening a dozen tabs from them).

I agree, since Firefox made this change, I’ve pretty much lost all interest in access keys.

Joshua says:
January 04, 01h

I noticed your use of Access keys when I first installed Sage in Firefox.

The default to open the Sage sidebar is ALT + S, which, of course, does not work on mezzoblue. Instead the page jumps to the beginning of your page content (per the standards you linked to). It’s no big deal really; it just happens that mezzoblue is the first site I visit most mornings before I move on to Simplebits….
(I just open sage there) ;)

January 04, 01h

I look at accesskeys the same way I look at any potential website functionality or piece of content: if it’s not the response to a clearly defined need, it doesn’t get implemented.

Web apps may leverage them, websites which need to accomodate disabled users and/or comply with particular regulations may require them, but your average, wide-audience, mom-and-dad website can very probably do well without them.

Dustin says:
January 04, 01h

I mainly only use accesskeys for things that folks do repetitively…for instance a “previous and next” deal
if you have 30 images in a photo gallery, it would be much nicer to just hit “alt + >” for the next key considering the user has no add-ons like the “next please” extension for mozilla.

January 04, 02h

I use keyboard navigation in preference to mouse navigation where possible. I have styles in my user stylesheet that reveal accesskeys and tab indexes.

Accesskey shortcuts to major parts of a page (navigation, content, search, next, previous) are helpful and quick to implement, but I wouldn’t bother trying to add mnemonic accesskeys for every navigation item in a site.

I doubt there is a accesskey solution that works flawlessly across all browsers/platforms/devices, but then this is the web which is pretty ephemeral at best, and todays solutions probably won’t work tomorrow anyway.

Mike D. says:
January 04, 02h

Ah yes, I think you and Jonathan are correct in that Gmail uses javascript to catch keystrokes instead of true accesskeys. So I guess I should amend every mention of the word “accesskeys” with the phrase “custom key commands” in my original comment. Concept still fully applies though…

January 04, 02h

I disagree for a change ;)

On one of the biggest tech-forum in the Netherlands we have had accesskey support for years, and recently expanded the possibilities for the users. All of the most-used actions have default accesskeys defined, but we allow the user to re-assign these keys to their own liking (this can also be used to work around the built-in browser keys that vary per browser and language).

I am using these keys very frequently on this forum, and I know that a lot of other users do too…

Dave S. says:
January 04, 03h

Beto and Tino —

If you have a demonstrated need, and the users of your sites are thanking you for them instead of complaining about conflicts, then continue doing so. It sounds like your situations benefit from them.

As for what’s wrong with them, go back and take a look at the WATS articles. In short, there are very few accesskey combinations that don’t cause conflicts with software defaults, and even if there are safe combinations, JAWS users are known to customize their keyboard configuration for their own purposes.

As for Bobby and AAA, most accessibility experts will tell you that a) Bobby is an automated tool that doesn’t check nearly enough of the WCAG guidelines to be considered an authority on what’s accessible and what isn’t, and b) AAA is a pipe dream anyway since the guidelines are ambiguous and aging poorly. So implementing Accesskeys for the sake of Bobby isn’t a reason to use them, to me.

Wayne says:
January 04, 03h

When I saw Accesskeys being used in Zen Garden, I found them to be very helpful in navigating the layouts. I believe that they have their own place, but nobody should expect to find them in their current form on any website.

Johan. Belgium says:
January 04, 04h

Imagine back in the days your scroll mouse mallfunctioned then you could access the page with the tab key and enter key. So accesskeys are not new to that matter. I believe that I prefer to use accesskeys more for a game. Concerning css for the blind and death or disabled I see access keys in every form (speech, light switches) and a future

Website Usability Advancer says:
January 04, 07h

It will only be useful if we make them a standard. I.e. “h” reserved for home page, “n” for next page, “p” for previous page (In listings), etc…

Otherwise it is counter productive to educate a person on how to use your website.

Users will not remember the keys that easy, they will need to return to your little “manual” several times.

Learn from Windows. Do you know many users that use the keys? I know that Ctrl+C and Ctrl+P are frequently used, but anything else? Not really…

Thus it’s a waste of time unless it is standardized.

Martin says:
January 04, 10h

If you look at the bigger picture (and things like viability in terms of time/cost), the effort could be much better spent fine-tuning other more directly beneficial aspects of a site - I’d rather be fanatical about things like content structure instead.

January 04, 11h

Huzzah! Not only is it rarely used, but it can sometimes cause frustration when going to sites that don’t implement them. For example, many IM applications allow you to use a variety of key combinations to “send” your message. I worked on a project that allowed users to supply notes to existing bug issues in a customer feedback application. Since each additional set of notes caused an email to be sent to all, it seemed, in the eyes of the users, that the application was like an Instant Message application (minus the Instant part). Thus, they demanded that the page where they add notes allow them to use Alt-S to “send”.

Thus, due to a certain design decision made for some IM clients, I had to make a change to a web-based application to mimic that behavior. Are we ready to have a set of clients who want a variety of behaviors mimicked in web applications that were never intended?

Again, huzzah, for choosing to abstain from their use. Makes for a safer web.

kadavy says:
January 04, 11h

I agree that they are not worth it, and there is too much risk of conflict with browsers. I like keyboard-only browsing, but simply using the accessibility preferences in Firefox make it possible to select links just by typing the text in them.

There have been many times, however, that there was a keyboard shortcut for “Next” and “Previous” for long articles or picture galleries. Again, however, it would be difficult to avoid conflicting with browser preferences. Maybe the user could specify the shortcut they prefer in their preferences, and then “Next” and “Previous” could be called out in the code.

January 04, 11h

I agree that I don’t personally find them very useful, but, then again, I don’t browse with the keyboard often. I have, however, received very positive feedback from blind users on some of the sites on which I have implemented them. Being that I normally keep all of my navigation in reusable functions, I don’t find it very difficult to manage accesskeys for the main and utility navigation for a site. I refrain from applying accesskeys to any links beyond that first tier as that would be a management nightmare.

Mike D. says:
January 04, 11h

Accesskeys = Worthless for web pages, invaluable for web applications.

Key commands only have value if a) they are standardized across all web sites (which will never happen), or b) they are used extremely frequently at any given web site… as in, a web application… as in, Google Mail.

I say, if you’re developing a web application like Google Mail or Flickr or whatever, go ahead and use the hell out of accesskeys. But for a site? Stay away.

Dave S. says:
January 04, 11h


Photo gallery next/previous are a great example of where Accesskeys could shine, conflicts notwithstanding. Discoverability is the main problem there, so an explicit label would be necessary.


I thought of GMail as I wrote this — does it use Accesskeys, or Javascript that hooks into keyboard events? I sat on the sidelines and never bothered getting an account; what I’ve heard about it makes it sound like they’re relying more on script than anything, but obviously I have no idea.

Jarrod says:
January 04, 11h

I think accesskeys work great in web applications, but with those applications you typically have a manual, or helpfiles that will explain the accesskeys.

For intranet web sites, I agree they aren’t really useful, but for intranets, extranets, and other web applications they can be a huge timesaver.

January 04, 12h


GMail relies primarily on JavaScript and IFrames to operate. Although it completely disregards standards of any kind, it is more usable than any other web-based email application I’ve ever used. It does not appear that accesskeys are being used, though the code is very sloppy (due to apparent server-side output). You are probably right in that they are using JavaScript to “hook” onto the keypress event.

I think accesskeys, like tabindices, can be very useful. While tabindices are usually not necessary (since user agents tend to put them in the order that they are in the code), they can be in the event that a link or group of links is positioned in a location before other links that come first in the code. Accesskeys can, I believe, be very useful. Perhaps I am the only one, but I rarely use the mousepad or wireless mouse. Instead, I navigate web sites and operate my entire computer through keystrokes. I will study the articles you linked to, but as of now I support accesskeys because I think they enhance usability - not particularly accessibility - in a lot of ways. Thanks for bringing up the subject, though. It has inspired research. :)

beto says:
January 04, 12h

Well, from some time ago we’ve been implementing accesskeys on several choice site developments, so your “no accesskeys” stance leaves me with mixed feelings. The reason we’ve done it is because of the feedback of some users with disabilities, specially blind ones, that have found our approach particularly useful and our sites usable. Plus you need them if gaining Bobby’s “AAA” accesibility approval is important for you.

Now, these were sites whose topic is precisely resources for disabled persons so it made quite some sense to use accesskeys there. Perhaps not so if it were a designer’s portfolio site.

However I don’t get what’s the big deal about time and cost of implementing accesskeys and put a respective “title” attribute indicating them in the “a” tags - it doesn’t take longer than implementing and testing, say, a CSS hack in our experience. Perhaps because we work the navigation in include modules, as Aaron Gustafson suggests.

But I agree in that it would really make sense if there was some standarized consensus on the keys used with accesskeys - like “S” for saving and “O” to open files, etc. However that’s a pipe dream. We don’t implement accesskeys on every site we do (it’s not worth it on many cases) but on the other hand, I fail to see what’s so bad about using them.

January 05, 02h

We give our visitors an access key menu by providing a hidden div with the keys in it. This means you can have key for links that do not show on the page but still work site-wide.

If you have Firefox you press alt+M to get the menu.

January 05, 06h

Website Usability Advancer,
You mentioned “It will only be useful if we make them a standard. I.e. “h” reserved for home page, “n” for next page, “p” for previous page (In listings), etc…”

That’s great… if all of the users around the world only spoke English. However, using N/P for Next/Previous as a “standard” is quite biased to other users who can see no real connection between those values and the words for Next/Previous in their own language.

Of course, even just the use of HTML for foreign websites requires the implementation of tags that only had meaning in English (i.e., H for Header, P for Paragraph, etc.). From my point of view, the problem is that we’ve developed a foundation that is quite biased towards the English language and so everything else builds on that biased foundation.

Who’d a thought that HTML would become so universally used?

January 05, 06h

<quick side note>
When it all comes down to it, just don’t use the accesskey “D”
After all, that’s the only one I really care about :p
</quick side note>

January 05, 08h

We have implemented some acceskeys on our website. We used the UK government’s recommended accesskeys standard:

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 have read a few articles from accessibility proponents that suggest the adoption of this standard.

January 05, 09h

A great way to inform users of accesskeys are by using the :after pseudo selector. Although not producing a result in all browsers, users _who cares_ will get it. Furthermore this will allow them to be shown/hidden with the aid of a simple javascript…

[accesskey]:after {
content: “[” attr(accesskey) “]”;
margin: 0px 0px 0px 3px;

The above code would, on supporting browsers, display as something like “Accesskey [a]” as the link text (for a link with accesskey a)…

Andy Budd says:
January 06, 05h

Dave says “while there may be no explicit accessibility benefits”.

Hold on a sec, maybe I missed the memo but I’m not sure how you can leap from keyboard shortcut conflicts to stating that there are no accessibility benefits behind access keys. On what basis are you making this assumption?

Sure there are problems using letters which is why the UK Government Standards settled on a numerical system. This may still lead to some conflicts, however that doesn’t mean access keys are of no accessibility benefit at all. Isn’t that a bit like saying there is no benefit in web standards because browser implementation isn’t consistent across the board?

Or am I missing something here?

January 10, 02h

An interesting article with a useful update..

This debate will run and run for a while

Keep up the good writing, looking forward to the book

e-head says:
January 14, 11h

Accesskeys have great potential if you ask me.

Only one simple thing needs to be done to make them viable. Browsers need to let YOU decide the key combo used with accesskeys. e.g., you could choose to use ctrl+alt to access them, or ctrl-shift.

Right now only Mozilla makes accesskeys easy.

Also, most browsers hotkeys take precedence over accesskeys, so there isn’t any possibility of disabling the users normal keys. This is how Opera is anyways. Accesskeys in Opera are worthless, btw (ctrl + escape + alt + accesskey ? give me a break).

I use them on my site to nav between posts (ctrl+ [ or ctrl + ]), and also in the photo galleries.

The only other issue is discoverability, as has been mentioned.

They are a great idea and maybe the browsers will get there act together.

January 16, 07h

Well gang…

The debate rages on. At, we still advocate *not* using Accesskeys, for all the reasons we’ve always used. A recent development is one more reasons not to…

Recently, a team of students from the University of Texas wrote a Firefox/Mozilla extension plus a script to enable JAWS to interact with Firefox (see: As part of their development, they created “custom” keyboard shortcuts to allow the visually impaired user to cycle through the Headings on the page - Alt + 1 for <H1>, Alt + 2 for <H2>, etc. Oops…

Where does this leave the “UK Standard”? Which should take precedence - the UK Standard or the user agent? Our postion is pretty clear.

We encourage those interested in the full story to read the numerous article we have posted at