Mobile version (Display Regular Site)

Skip to: Navigation | Content | Sidebar | Footer


Weblog Entry

I Do Not Use Accesskeys

December 29, 2003

A standard is a standard is a standard. But what if those standards don’t work as directed?

Over time, I’ve come to the conclusion that Accesskeys are more harmful than good. Until browsers allow a user to override a document’s Accesskeys, I won’t use them.

The idea is a simple one: by using the accesskey="n" attribute on specific links in your HTML, you define n as a hot key that allows keyboard access to that particular link. Mark Pilgrim has more on the syntax and usage of Accesskeys.

WATS.ca has written a series of in-depth articles (Is it Worth it?, More Reasons…, Accesskey Alternatives) that go into the problems with this seemingly simple idea. Executive summary: key conflicts with existing browsers/operating systems/user macros prevent Accesskeys from doing the job as described.

The problem has been stewing in the back of my mind for a while. But it really hit home last week: I received an e-mail from someone complaining about a specific conflict that has been bothering me personally.

Go to the Zen Garden in any browser that allows the ALT+D key combination to select the address bar (IE and most Gecko browsers will do the trick, Safari will not). Try selecting the address bar from the keyboard. Instead of doing so, some browsers will select the fourth design from the list on the right, since that list has been assigned sequential keys from ‘a’ to ‘h’.

The annoyance factor is high, and in some cases it may be downright harmful. Accesskeys are a good idea; too bad they’re not practical.


Reader Comments

1
Lionfire says:
December 29, 08h

That’s why most browsers are moving towards control-keys for browser control, freeing the alt keys for access requirements. For example, ctrl-L is now the preferred way to get to the location bar in Mozilla (or open a dialog for a new location in IE).

The problem is we’re trying to support people who don’t/can’t use a pointing device while also trying to support a legacy of nonstandardisation. Someone is going to have to miss out here &mdash so the real question is which is more harmful?

2
Marko says:
December 30, 01h

Yes, I’ve been thinking about this, too. And the same problem is present regarding tabindex also, which is (among other standards) poorly supported in IE. Pressing ‘tab’ key in the freshly opened page will select adressbar(s) of the browser primarily, and then proceed with the actual document. More frustrating is that refreshing a page (F5) wouldn’t help if visitor lost tabindex sequence. In case of, one should open a new browser window or just keep pressing..

For me, this is just another standard which has neither actually been tested in real conditions, nor made completely..

Maybe we should keep making different versions of each page after all? Or make a list of unused letters in browsers/OS and stick to it? We still have numbers, don’t we? But they are not intuitive..

3
December 30, 01h

Some great comments flying around here - a few things to respond to, so I’ll try to do that here in one reply:

1. Jor – regarding the use of <a rel=”accessibility” >. We had suggested similar in that last article on Accesskey Alternatives (see http://www.wats.ca/articles/accesskeyalternatives/52#standardization ), and believe it would be better to include it in a LINK element than an A element for the most part, unless the links are actually “visible” links by definition. That will require more testing as well, for a variety of reasons, including browser support.

2. Dave – re: how to deal with a mass of links like on Anne’s site. I’m not really sure we need to deal with it that much for browsers like Lynx. We had also proposed using the LINK element as an alternative to using skip navigation links etc, so if you define a LINK to Page content near the top of the list of your LINKs in the HEAD, you’d be presented with that link almost first, which would deal with that problem. Of course other user agents may be different, but at some point the implementation would be up to them - we’ve done our job by creating the appropriate meta data. On our site, “Page Content” is listed as a LINK near the top of our list of LINKs.

3. Michael – re: the hierarchy idea. Yes, that would deal with one of the issues with accesskeys (i.e., conflict resolution). However, it still doesn’t deal with the issue of standardization and the usefulness of accesskeys. I still don’t believe that author defined accesskeys are the way to go. I’m all for us defining appropriate LINK rel types, and convincing browser makers to allow custom keybindings based on the users so that the users can define their own keyboard shortcuts to use on *every* site.

4. Opera’s lack of support for Numeric Accesskeys just seems to be the nail in the coffin. Numeric accesskeys had very little conflict save for some conflicts with Window Eyes (see http://www.wats.ca/articles/accesskeyconflicts/37#numwineyes ). Many site authors looked to numeric accesskeys as their last hope, and in fact, many governments have advocated/mandated the use of numeric accesskeys. We recommended to the Government of Canada in 2002 (when our accesskey research began) that they stop using accesskeys on their pages for some of these very reasons. As we’ve continued with the research, we’ve found them to be more problems than they are worth – we’d rather see some other method for providing the same functionality, but without the problems seen with the current implementation of accesskeys.

4
December 30, 02h

Standards are there for some time now. It’s surprising that many browser makers haven’t fully supported them to this date (correct me if I’m wrong).

Is it the sheer laziness or the lack of technology to implement them to their next product?

When considering the open-source development model (Mozilla in particular) it’s surprising that they also haven’t implemented it fully.

IMHO, it’s time that standard compliant web developers start to fill the missing pieces.

5
Jesper says:
December 30, 03h

Not to miss the point entirely, the address bar can be selected by F6 too in most browsers.

But yes, you make a very good point. What could be useful is using numbers (any web browser using numbers as menu access keys is retarded anyway :)), but I think all are taken.

6
Michael R. Havard says:
December 30, 03h

Derek:
I understand what you are saying about interpage navigation and that’s fine. My assumption has always been that accesskeys were geared more toward in-page navigation. I.E. moving THROUGH or TO a group of fields or navigating to a specific section of content within the page (<label for=”myInput” accesskey=”m”>My Input</label>).

Will the LINK REL be able to address this part of the navigation or do we still need accesskeys for that portion?

I think the context in which it’s being discussed here it seems more like “ALT-H” goes to “Home” page, “ALT-L” goes to “Links”, “ALT-A” goes to “About”. I personally think that’s a different animal and not meant for using accesskeys.

7
justin says:
December 30, 04h

Yes! Being an avid using of the Alt-D combo to jump to the address bar for years, this is an extremely ill side effect of the access keys. Although the idea of browsers moving their access keys to the Ctrl-D combo instead is moderately satisfactory, who decided to that Access Keys shall use the Alt-XX combo?

Is it not obvious that Alt-XX is the magic bliss of anti-mouse advocates and has been forever? Even in the crumpy DOS editor you can use Alt to get to the menu bar, surely choosing Ctrl-XX for the Access Key standard would have been a more suitable choice.

8
jgraham says:
December 30, 04h

So, access keys have implementation issues. That doesn’t mean that they, or something like them, are not a good idea. Clearly, there are two problems that need to be solved - how to enable rapid keyboard based navigation within a single document and how to enable rapid keyboard based navigation between documents. Clearly, for both cases, it would make sense to provide a convenient interface to the contents of the link elements. Effectivley, one one simply provide standard shortcuts for the items already visible in the Mozilla site navigation bar (Top, Up, Down, Previous, Next, Last). This would not cause any obvious problems. Links with a rel not in that defined list would be more problematic, but one can certianly imagine interfaces that would allow these to be accessed via the keyboard - a link sidebar for example.

The same is true of intrapage keyboard navigation to elements with a defined accesskey. These elements could be made avaliable via the (otherwise mostly useless) ‘go’ menu or via a sidebar - this would provide some keyboard access to important navigational elements, since the go menu can always be accessed via ctrl-g (or whatever). One could display the author defined access keys in the menu so that the user had a simple way of determining which keys were in use as access keys. Alternativley, a browser author may decide to ignore the accesskey part of the spec and instead implement a system where elements defined to have an accesskey were assigned a particular set of keybindings in some predetermined fashion - e.g. to the combinations alt+digit for each digit 0-9 according to order on the page. It wouldn’t be perfect, but it would at least prevent conflicts.

In short, I think that many of the current issues with accesskeys are implementation difficulties rather than anything more fundamental - although I would be interested to know of any alternative proposals that encompassed the same functionality but without the difficulties (the most obvious I can think of would be to provide a simple attribute that indicated that a keyboard shortcut should be assigned to a particular element, relying on the UA to implement the actual shortcut, with predefined shortcuts for particular valoues of ‘rel’). Moreover, if the majority od UAs support numeric accesskeys and they cause few problems, I don’t see the lack of support from opera being a reason not to use them. It;s difficult to see any substantial disadvantage and if they come into wider use, Opera might be encouraged to add support.

9
Jor says:
December 30, 05h

In my opinion accesskeys are a flawed concept to begin with. While MSIE and Geckos allow basic keyboard navigation, Opera uses nearly the complete keyboard for navigation, so accesskeys are delegated to a special accesskey mode. Thus alt+D does not select the accesskey ‘d’, but ‘shift+esc-and-then-d’ does.

Accesskeys are badly documented, there is nothing in the spec detailing how they should be made visible, and since unlike the LINK types there are no standard accesskeys defined at all, there is little or no consistency across website, requiring a user to relearn accesskeys on a per-site basis. I’ve even encountered situations where page A of corporate website N had accesskeys defined, but page B of the same website had entirely different accesskeys.

I’m all in favour of dropping them completely: a far better accesskey scheme could be devised using the LINK types. Remember <a rel=”accessibility” title=”accessibility statement” href=”foobar”> is perfectly valid HTML! A user could then simply map a button or keypress to the ‘accessibility’ link type, and know that no matter what website he was on, he would go to the accessibility statement.

10
December 30, 06h

I am re-thinking accesskeys too. If they ultimately lead to something less accessible then, as you say, they do more harm than good.

Someone also emailed me recently about my site asking why, when they pressed a certain key combination, the browser did not do what they expected. Obviously, one of the accesskeys attached to a navigation element was overriding a keyboard shortcut for the browser.

This is a shame, because the idea is a good one (although there is that other problem of how you let the user know what the accesskeys actually are!). Maybe there are certain keys that have an improbable conflict, such as the numbers maybe?

11
Josh S says:
December 30, 06h

Plus this would majorly conflict with the Moz/Firebird feature of automatically searching the page for what you type. I would get pretty ticked if I started typing a word then ended up on a whole new page or whatever!

12
December 30, 07h

As Jor pointed out, and somethng that we first commented on in November, there are other options to provide similar functionality – they just need further development.

We do like the idea of allowing the end user to map keystrokes to activate links that have specific relationships defined via the rel attribute – put the user in control.

Philosophically, I believe we should not be defining accesskeys in our documents, but rather we should be defining proper LINKs to those areas we see as important (we need to expand on the list of rel attributes that are defined by default within HTML), then allowing the users to define their own keystrokes to invoke them. That way, I can use whatever keystrokes I want to get to the HOME page, the CONTACT form, the SEARCH form if it exists, the ACCESSIBILITY statement, and we don’t have to standardize accesskeys across different sites, because we leave it to the browsers/users. I use what I want, you use what you want, and we have less conflict to worry about…

The number of sites that use accesskeys is still relatively small, yet they are mired with conflicting choices for accesskeys. Even sites that say they are using “standard” accesskeys are free to add in whatever they like, making it difficult to claim any sort of standardization at all.

That is why we think we need to look at different methods as we outlined in the last article Dave pointed to – Link Relationships as an Alternative to Accesskeys (http://www.wats.ca/articles/accesskeyalternatives/52)

13
David House says:
December 30, 07h

Then surely the problem lies not with the accesskeys themselves, but with conflicting use of them. Try to avoid browser hotkey combinations, and wouldn’t accesskeys be great?

14
Joe says:
December 30, 07h

Heh, I ranted about this back in September, also got some good feedback in my comments:

http://bitworking.org/news/Please_do_not_use_D_as_an_ACCESSKEY_in_your_HTML

15
Dave S. says:
December 30, 07h

> Try to avoid browser hotkey combinations, and wouldnít
> accesskeys be great?

Read the linked article “Is it Worth it?” – The conclusion reached is that there are only three keys that *don’t* cause conflicts, at least on English sites:

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

I believe LINK is the way to go, but I’m concerned about various implementations. Since, for example, Lynx dumps all LINKed items at the beginning of the document, theoretically if you have a site that lists a ton like Anne’s - http://annevankesteren.nl/ - you’ll need a special “Skip Nav” link for your LINKs, no? How would one go about implementing *that*?

16
Jesper says:
December 30, 08h

<link rel=”bookmark” href=”#top” title=”0 Skip Links” >
[..]
<body ..><a name=”top”></a>

;)

I really like Jor’s suggestion about rel=”accessibility” or something to that effect.

17
Michael R. Havard says:
December 30, 08h

I think, as with any standard, the browser makers need to see significant pressure in the form of use (or abuse) of the standard before they will step in and make changes to the browser.

If we abandon use the manufacturers assume it’s not needed, not that the browser is broken. So our best bet is to attempt to use the standard whereever possible and then yell at the individual browser makers to resolve the very real accessibility issues caused not by the standard but by their applications.

Accesskeys and tabindex are accessibility tools. The application developers just need to find a way to support them properly.

My choice for accesskeys would be to set up a hierarchy. For example: The first time you hit “Alt-H” the applications looks at where the focus is, is it on the page? Is there an accesskey “Alt-H” for the page? Yes? Use it! No? Then travel up to the application level and see if there’s an accesskey “Alt-H” there. Yes? Use it! No? Then travel up to the OS level and pass the Alt-H to it so that it can go on to either the OS or some hotkey helper application. An additional keypress on H would tell the application to move immediately up the chain if I know “that’s not the alt-h I want”.

In that scenario if the page has focus and I had Alt-e as an accesskey to an e-mail field then Alt-e would put a focus on the field whereas Alt-e-e would would go to Edit on the file menu. Then you could have accesskeys without worrying about real conflict. Accesskeys then become somewhat like Alt-TAB taskmanagement just Alt- then TAB until you get the selection you want.

18
December 30, 08h

Dave, did you get an email that looked anything like this? It’s possible you were a victom of a automated email campaign to get webmasters to start using accesskeys…. not sure why someone would send out automated emails like this, but this email has been sent to several people I know:

————-
Dear Webmaster,

Just a quick suggestion, since I cannot find it in your accessability statement… How about adding keyboard shortcuts to
some of the links on your site?

As well as being quite important to disabled people and the elderly, they also make everything faster and more convenient
for everybody else, too.

They work on almost all version 5 browsers, and clearly do not interfere with older (or non html-compliant) ones.

The code is simple enough:
Search

The above produces a link that can be activated by the user pressing Alt+4 on their keyboard. In theory, any character can
be used, but in practice, most letters cannot be used, since they may interfere with the browser’s own hotkeys for the menus.
However, some common numeric standards are emerging,
for example:
1 Home Page
2 Skip Nav (or What’s new)
3 Site Map (or Printer Version)
4 Search
5 FAQ
8 Terms Of Service
9 Feedback
0 Accesskey List

The above scheme is now in use on every UK government and council site, as well as on healthcare sites, and now also on USA
academic sites, Australian Government sites, and mainland Europe commercial sites.

Something to think about… Companies around the world are spending trillions on wheelchair access for buildings and
carparks, and there are many US, UK and international laws coming into force to require this (508, and the Disability
Discrimination act is only months away)….

Thanks for listening.

19
Dave S. says:
December 30, 09h

Nick, I believe I did get a copy of that a month or so back. Interesting that someone is concerned enough about accessibility that they’d resort to spam.

jgraham - It’s most definitely an implementation issue. While your proposal is rather interesting, I’m faced with the reality of what is supported right now. In their current form they just don’t hold up well.

Aside from conflicts, discoverability is a problem. If a numeric standard were to be followed, that would cut down on confusion. But it would also limit the functionality; the proposed numeric ‘standard’ doesn’t take into account, for example, web apps.

One thing WATS didn’t cover that I can only put forward as hearsay is that JAWS allows custom mapping, and many advanced users will have a lot of customized key combinations already setup. Conflict with those, and you’re hurting the very people Accesskeys were built for. Again – hearsay, not first-hand experience.

20
December 30, 09h

Isn’t it a solution to use accesskeys and tabindex together? Let’s say yoy have multiple <ul>’s for navigation. Give the first item of each one a numeric (I don’t think those are being used by the browser themselves) accesskey and from there let it over to the tabindex. As far as I know when you use an accesskey it jumpes then to the first item. Hitting tab will jump the focus to the second.

21
Michael R. Havard says:
December 30, 11h

Sjors:
Unfortunately not all browser recognize numerics as accesskeys (OPERA).

22
mpt says:
December 31, 01h

This problem is *so* three-years-ago. See http://bugzilla.mozilla.org/show_bug.cgi?id=51940#c4 . ACCESSKEY is just one of the many things the W3C wouldn’t have codified if they cared about usability.

And for general comments on Web authors complaining that they can’t do all the cool stuff application authors can do (accesskeys being an example), see http://geocrawler.com/archives/3/138/2001/4/100/5508135/ .

23
jgraham says:
December 31, 03h

> While your proposal is rather interesting, I’m faced with the reality of what is supported right now. In their current form they just don’t hold up well.

Yeah, I know. But I’m interested to know whether this is an implementation issue or it’s a fundamental problem with the accesskey spec. If it’s just a case that implementations of the spec are poor, then the best that anyone can do is make an extension (or even a full blown patch) for their choice of browser (assuming they use a browser where user extensions are possible) and hope that people pick up on it so that support in general improves. If, on the other hand the spec is impossisble to implement in a satisfactory way, then this discussion should be happening on www-html, not here. (Incidentally, the most informative reference that I found (after a very brief search) about accesskeys on the w3c public mailing lists is http://lists.w3.org/Archives/Public/w3c-wai-ig/1999OctDec/0725.html ). This supports the view that problems with accesskey are iimplementation problems rather than spec problems.

Incidentally, another approach to avoiding the keybinding clash problems is to avoid using standard command keys to access accesskeys. One could use a mechanism consistent with the typeaheadfind in mozilla and use say # to put you in a ‘go to accesskey’ mode. The fact that the spec suggests using alt or cmd as a modifier to get to the accesskey is imho a bug in the spec that is responsible for many of the current issues.

24
December 31, 05h

Dave – the custom keystroke mapping in JAWS, WindowEyes, and Opera is what eventually lead us towards suggesting things being user configurable. In using JAWS and WindowEyes for minor testing I saw the *very* high degree of end-user configurability in terms of keystroke access. WindowEyes as an example reserves Alt + 0 through Alt + 9 for user defined “windows” that represent different areas of the screen. The keys can be reconfigured to allow the user to remap the keystrokes to something else if they choose. Same appears to be true for Opera in terms of defining keystrokes there via Edit > Preferences, and then modifying the keyboard setup. It is very easy for instance to change the Open dialog box from ctrl + o to simply the single keystroke o if I want to.

Many of the issues that we have pointed out are implementation issues. However, we believe that there *are* other issues to be dealt with at a higher level.

We believe that we are moving towards an end goal of putting the user in control. To us, this means providing a mechanism for rapid keyboard navigation in the user’s User Agent of choice, based on what the user defines in their preferences rather than what the authors of individual sites decide is an “intuitive” key to use for a particular shortcut. Current implementation and philosophy of accesskeys don’t support this end goal.

That is what eventually convinced us that there needed to be another way of providing the same type of functionality. Seeing that end user configurability and the W3C User Agent Guidelines are leaning towards allowing for binding of custom keystrokes to different actions meant that author-defined keystrokes could eventually become meaningless anyway.

So, if we need to make significant changes to the way things currently are anyway, we believe that we should be asking the questions that we have been asking for a while (use of “we” in these questions is a global collective we): “What *should* we be doing?”, “Can we look for/develop a different solution(s) that will not have the same implementation problems?”, “Can we come up with something that is more ‘standardized’ for the benefit of all?”, “Can we come up with something better?”

As for where the discussion should be taking place – we see it all the time on discussion forums, on the WAI list, on the WebAIM list and others. Whenever it pops up, we participate.

In every forum in which we participate, and in our own resources/articles that we post, we are also very careful to state clearly that:

1. We like the idea behind accesskeys,
2. We find the implementation very problematic
3. We believe that we collectively need to examine the issue and determine if we need to develop other solutions that better suit the needs of everyone.

25
jgraham says:
December 31, 05h

For what it’s worth, bugzilla links about getting keyboard access to the link elements in Mozilla:
http://bugzilla.mozilla.org/show_bug.cgi?id=102909
http://bugzilla.mozilla.org/show_bug.cgi?id=104586

The usual “Don’t comment unless you have something significant (e.g. an implementation) to add” disclaimer applies.

26
December 31, 06h

jgraham wrote:

Yeah, I know. But Iím interested to know whether this is an implementation issue or itís a fundamental problem with the accesskey spec. If itís just a case that implementations of the spec are poor, then the best that anyone can do is make an extension (or even a full blown patch) for their choice of browser (assuming they use a browser where user extensions are possible) and hope that people pick up on it so that support in general improves.


*Of course* this is an implementation issue. One browser that does it right is Mac Mozilla. Keyboard shortcuts are Command-key; accesskeys are Control-key. No conflict; no problem.

If other browser writers are too lame to implement accesskeys properly, that’s no reason to punish users of browsers who can use them.

And the target audience of Accesskeys is more than just “JAWS users”. It’s anyone who doesn’t use a mouse for navigation. That could be someone with Carpal Tunnel, using voice-actuation for navigation. It could be someone browsing in a text-based browser, …

And, as to the proposed alternative of providing client-side configurable key-bindings to the <link rel=”“> elements, that’s a fine idea, but it’s *foolish* to assume that such keybindings would be useful across sites. Web authors are no more likely to “standardize” on a common set of link targets (beyond the predefined ones) than they have on a common set of accesskeys.

Lynx provides keyboard access to the <link rel=”“> elements on a page. Mozilla and Opera expose them to the user, but don’t provide keyboard access. it would be nice if they did.

But, even if they did, web authors would still gripe and complain and not use them, because “Browser X” doesn’t support it.

27
jgraham says:
December 31, 07h

> *Of course* this is an implementation issue. One browser that does it right is Mac Mozilla. Keyboard shortcuts are Command-key; accesskeys are Control-key. No conflict; no problem.

Well ‘m not sure it’s so obvious. The reason it works on the Mac is that there are a larger number of modifier keys than on most other platforms and the command key is largely unused (the links mpt posted suggest that it can be bound to user macros). At the very least, I think the part of the spec that suggests using modifier keys to access these functions should be removed - modifier keys are already used in complex platform and application dependent ways that a document author cannot hope to antcipate over the full range of platforms. Even though this part of the spec is clearly informative, it appears to be bad advice.

> Web authors are no more likely to ďstandardizeĒ on a common set of link targets (beyond the predefined ones) than they have on a common set of accesskeys.

Well having the standard link targets avaliable for keyboard navigation would be a huge improvement in itself. This really is an implementation issue. On the other hand, if there are widely used link targets that are not standardised, maybe they need to be standardised too (that doesn’t even require a html rewrite - one could simply produce a specifcation like a more useful version of xfn ( http://gmpg.org/xfn/index )). One can imagine rel=”document-body” for a skip navigation type link and rel=”navigation” for a link to a set of hyperlinks, for example. Getting people to support such a specifcation is, of course, harder, but that’s a different problem.

> But, even if they did, web authors would still gripe and complain and not use them, because ďBrowser XĒ doesnít support it.

Sad, but apparently true.

28
December 31, 08h

jgraham wrote:

“The reason it works on the Mac is that there are a larger number of modifier keys than on most other platforms and the command key is largely unused.”

The Mac does not have an unusually large number of modifier keys. It has 3: Command, Option and Control (4, if you count Shift).

It just uses them more intelligently.

Application keyboard shortcuts are always Command-key. And you can combine modifier keys, so applications with a large number of keyboard shortcuts might avail themselves of Option-Command-key or Shift-Command-key as well.

So, using Control-key for accesskeys is wide open.

You are completely correct that the Spec should not have suggested implementation details. That should have been left to browser writers. HTML specification-writers clearly aren’t user-interface experts and, even if they were, they should not presume to dictate the user-interface in all browsers on all platforms.

29
Christian Rocha says:
December 31, 09h

I agree strongly with Derek Featherstone’s view that rather than relying on authors’ proprietary sets of keyboard navigation we should “provide a mechanism for rapid keyboard navigation in the userís User Agent of choice.” We have to learn separate sets of keystrokes per browser anyway–it makes perfect sense that standard navigation be the responsibility of the browser.

Though not really keyboard-based, Opera has an interesting answer to standard data in that it displays the links as buttons above the web page. Examples can be seen on the following pages when viewed in Opera:

http://www.wats.ca/articles/accesskeyalternatives/52
http://diveintomark.org/archives/2003/12/28/http-tests

I believe it is safe to say that unlike us, non-computer enthusiasts generally dislike keyboard shortcuts and find them much trickier than pointing and clicking. If browsers were to implement something like Opera’s visual solution AND assign them some kind of keystroke we’d have an excellent solution to our problem.

30
Michael R. Havard says:
December 31, 09h

To me the problem is still one of implementation vs. specification. Access key behavior from the W3 documentation is pretty clearly defined.

The problem comes in the fact that:
1) Each OS has it’s own methods of dealing with keyboard shortcuts.
2) Each user agent has it’s own methods of dealing with keyboard shortcuts.
3) Each user has his/her own method of dealing with keyboard shortcuts.
4) Helper applications have their own method of dealing with keyboard shortcuts.

And there’s no management process available to allow all these differing methods to meld.

In general on Windows it works like this (I say in general because there are stupid exceptions ALWAYS):

Alt+KEY handles on screen elements (navigating to a field or through a menu).
Ctrl+KEY handles context menu/application level elements (Copy, Paste, Print, etc).
WinKey+KEY handles OS level elements (Starting applications or opening dialogs quickly Winkey+E for explorer or Winkey+R for run).
Ctrl+Alt+KEY/Ctrl+Shift+KEY handles user defined shortcuts.

So at least for Windows there are two fundamental problems with conflict resolution for duplicate shortcuts and third party applications that override the guidelines (like shortcut/macro programs or helper applications).

I think that there is something that you can do about the first problem. Which I stated in my previous post. We need for the application or the OS to have a keyboard shortcut conflict resolution mechanism. The second problem you can do little to nothing for.

It will never be perfect…

Part of why all of these helper applications have sprung up and created their own keyboard shortcuts is because of a lack of consideration by the developer community as a whole to attempt to conform to a years old standard. The problem ends up being the AOL/ADA problem:

Years ago AOL’s software was not screen reader compatible. AOL made the statement that “If more blind users subscribed to the service we’d have more incentive to make the software accessible”. Of course how many blind users are going to sign up for a service that they can’t use. So which should come first - USE or USEFULLNESS.

Right now there’s no incentive for the browser makers to do anything different. JAWS et al already do a lot for keyboard navigation. So should we throw our hands up and just say to hell with it? If that were the case we’d all be using MSHTML right now.

I say use the standard where you can. If it reaches 86% of the userbase and they see it as good, then great. If the other 14% can’t use that EXTRA feature (that’s based on an existing standard) then maybe they’ll complain to the browser manufacturer for a better implementation. We have to put pressure on the manufacturers to do better. It’s a must.

31
Dave S. says:
December 31, 10h

“One browser that does it right is Mac Mozilla. Keyboard shortcuts are Command-key; accesskeys are Control-key. No conflict; no problem.”

Just expanding on this thought - the problem in casting a spotlight on a Mac browser is that the Mac OS is more or less impossible to use without a mouse in the first place. Maybe this is my relative inexperience with the system talking though, it’s true I’ve only been a user for a few months.

Changing gears - I’ve been a mouse user for over ten years, it’s an extension of my arm at this point. And yet I *need* keyboard access to my operating system and my browser. It’s the way I work.

So to someone like me, Accesskeys are a great idea. I’d love to see the proposed numeric standard take hold, nothing could be better than relying on one set of keys to do exactly the same thing across all sites you visit. It would be great if I had control over what those particular keys are, of course.

Looking at the spec, if I’m reading this right, the conflict I originally started this thread with (ALT + D) is actually valid and expected according to UAAG - http://www.w3.org/TR/UAAG10-TECHS/topics.html#input-config-res - just highly inconvenient, and problematic (especially considering the other half about ‘alerting the user’ doesn’t happen) Spec problem or implementation problem? Probably a little of both.

Derek, you’ve done well highlighting the current issues with the technology, and how things might change. It’s where I have to leave the discussion, since my own agenda lies in what’s practical today. But with people such as yourself working to better the technology, I’m sure we can look forward to a useful alternative.

32
Ian says:
December 31, 10h

I didn’t see any mention of using F6 to access the URL bar… It works for me in IE6 and Mozilla. Has anyone tested this in other browsers. This makes the Ctrl-D issue a non-issue.

33
Tony says:
December 31, 12h

Ian,

For me, in Mozilla, F6 brings focus to the search field in my sidebar search…not the same as alt+d, which brings focus to the address bar.

Even if F6 did work the same, all the time, as alt+d…it’s much harder to use as a shortcut since it requires moving your hand from the home position (unless you have REALLY long fingers.)

I’ve been thinking about this issue recently as well. I tried making my access keys (for site navigation) make sense to the user, and used CSS to label them as such (underlining the accesskey letter in the actual link.) Still, it bothered me that one or more of these keys may be used for something else on the users computer. I thought about switching to numbers, but the comment that WindowEyes reserves atl+number for it’s own use has swayed me. For now, access keys are gone.

34
jgraham says:
January 01, 04h

> http://www.w3.org/TR/UAAG10-TECHS/topics.html#input-config-res

That part of that document seems rather far removed from reality. As far as I know (although I may be wrong) applications have very little in the way of ability to detect keyboard conflicts. In Mozilla, for example, I believe that keyboard events “bubble” up through all the possible layers that can handle that event. Any event can call preventbubble which will stop any higher level events from finding out about the keyboard event - so they have no way of knowing that there is an event that they have missed. Now I suppose that one could, in principle provide some additional communication between layers to detect conflicts. However, there must be a similar mechanism that passes unhandled events to the operating system. As far as I know (and I could be wrong), there is no way for any application to tell if the OS will do anything with an event that it passes - so detecting conflicts is in fact impossible (modulo operating system rewrites).

Assuming that one could detect a conflict, it’s not clear how much alerting the user would help. Given that the majority of users ignore alerts (presumably this would have to be a status bar type alert, since an alert that interrupted workflow would make keyboard navigation useless for people who did want to use it), they’d still wonder why alt+D wasn’t focusing the location bar but was instead scrolling the page.

The most useful suggestion there is to place the author bindings in a menu , so that one could guarentee a shortcut of the form ctrl+menu access key+element accesskey, although one couldn’t have two items with the same accesskey in this scheme.

> The Mac does not have an unusually large number of modifier keys. It has 3: Command, Option and Control (4, if you count Shift).

That’s one more than the number of unique modifier keys that are expected to be on a PC keyboard (ctrl, alt, shift). Admittedly, Alt and Alt Gr are actually different, but I’m not sure if all operating systems (or all keyboards) make this distinction. Additionally, many recent keyboards have the Super (or Windows) key - but this is *another* key that is used for OS level events.

> nothing could be better than relying on one set of keys to do exactly the same thing across all sites you visit.

The obvious problem being that all sites are different, and so might have different concepts of what doing the “same” thing entails. Moreover, different sites have different elements that would be considred important.

> Itís where I have to leave the discussion, since my own agenda lies in whatís practical today.

Well no one has really covered the options. For example, define a set of accesskeys and provide a script to disable them. Or produce two versions of the page, one with accesskeys and one without. Provide a list of accesskeys and the option to switch to the alternative version of the site (controlled by a cookie on subsequent visits) if the user experiences conflicts. A lot of work for a little gain? Probably, but these things are still possible.

35
January 02, 06h

coming in late on this, and it’s probably already been said, but…the point of accesskeys is to provide a minimal set of shortcuts. having more than a handful of them is actually more harmful and confusing than not having them. unless the site is visited on a regular basis, users will not bother to learn all the keys. having only the accesskeys for skipping to content, the search field, etc is the best solution, and in most cases (sticking to the numeric accesskeys) should not conflict with any other key assignments…

36
matt wilkie says:
January 06, 01h

I used to use Access Keys all the time for the pages I put together for our intranet. However since I discovered Type Ahead Find in Mozilla I’ve been using that instead. It works on any page on any website with no effort from the designer (as long as they are smart enough to use “click here” for everything; and don’t use images-for-links all over the place). Also there is no need to memorise anything – just type what you are looking for.

I sincerely hope all browsers implement a type-ahead find feature. It is the best browser innovation I’ve seen in a long time.

37
Richard says:
January 07, 11h

The first thing to notice is that wats.ca don’t really know what they’re talking about. They state that M can’t be used as an accesskey because Alt+M is reserved in Opera. But then Opera doesn’t even use Alt to invoke accesskeys!!

Marko- you wanna create a list of unused letters in every browser/OS? It’s gonna take you a while to cover every language. And then what do you do when you’ve only got ] left?

Numbers are obviously the way forward (and I’ve got them to work with Opera 7.22 on Win2K, so I’m not sure about the people who say they aren’t accepted). Aside from avoiding conflict, they are also usable on the new generation of internet devices. Think mobile cellphones, and the remote pads of MSN-TV set-top box (they only have 10 keys anyway!). A worldwide standard has already been set up, and without any other standard to compete with, it has been widely adopted. They are also pretty intuative:

http://www.lacarte.org/about/access/keys

Chintana- it’s not that the browsers offer buggy support. They don’t. They support them fully and perfectly. Accesskeys are supported on all browsers on all OS (with the one slight exception of Safari). IE4 had them in 1997. Netscape has them from 2000, so does Opera, iCab, Mozilla et al, Phoenix/Firebird, Amaya…

LINK REL types are OK for links, but what about form elements? No luck there.

Michael- I like your hierarchy idea for screenreaders.

And the other idea about browser-configurable modifiers, or “accesskey mode” sounds good as well. Alt is only a suggestion, but some other combination might also work. (how about Alt+Shft? or even Control+AltGr?)

If you’re going with letters, then a Satus bar type alert sounds like another good idea. Maybe even ask the user in the settings if they want to dismiss all page-accesskeys that conflict with the browser ones…

38
January 28, 09h

I guess accesskeys are supported by at least all major browsers. But every browser define’s its own HotKeys and functionality.
Therefore, you can add a help page with information about the use of accesskeys with diverse browsers. Or?

39
February 20, 08h

> The first thing to notice is that wats.ca don’t really know what they’re talking about.

Ahem…

We acknolwedge and have now stated the fact that Opera does not use the Alt + _ keystroke combination to implement Accesskeys on the Keystroke conflict resource page of our site. It was an editorial oversight rather than a lack of “knowing what we are talking about…” (Curiously, many proponents of Accesskeys, on their page which maps their personal implementaion of site accesskeys, also use the phrase “Alt + _”, when in fact depending on the browser and/or OS, it may in fact be something completely different - right Mac users?)

However to set the record straight (and in the interest of completion), in Opera, to activate a letter accesskey, you hold down Shift + Esc + letter. When using numbers on the other hand, you must press Shift + Esc, let go, and then press the number.

We continue to stand by our overarching position though, that Accesskeys are a failure in their implementation and usability/accessibility and that the development community (that’s us, guys and gals) need to come up with a better alternative.

40
March 24, 07h

Just discovered this interesting article/discussion while composing a posting on macosxhints about accesskeys in Safari. I’ll just copy+paste most of that here:

Anyone here know how to disable accesskeys in Safari? They interfere with “emacs-style” control key shortcuts I frequently use while composing messages on several forums. For example, control-p often activates “preview post” instead of moving to the previous line. Or control-b inserts bold UBB code markers. Even worse, I’ve accidentally posted something that couldn’t be edited or deleted without even realizing which accesskey did it.

One option for Safari might be to disable accesskeys while keyboard focus is in a text input widget (or whatever it’s called), but this ain’t my area of expertise so I’m not sure if that’s the “right” thing to do or if the current behavior might actually be a bug.

Jacques Distler wrote: “So, using Control-key for accesskeys is wide open”.

Unfortunately that’s not true, per my example. It’s my main issue (and gripe) with accesskeys in Safari. Bug or not, they’ve downgraded my browser usability, apparently without any immediate recourse. Same may hold true for OmniWeb 5, which I’ll be checking soon now that this topic has interrupted me.

41
August 16, 11h

Just one final follow up on this post, as we’ve just added to our articles on accesskeys.

The latest working draft of XHTML 2.0 no longer includes the accesskey attribute and replaces it with a new “access” attribute that has more power and flexibility.

I’ve posted more detail in our latest article: The Future of Accesskeys
http://www.wats.ca/articles/thefutureofaccesskeys/66

42
November 16, 11h

I find that one of the facets lacking in the discussion of Access Keys is that of Internationalization (I18N). I recently worked on a project where we were converting our website for B2B to allow for various translations of the same dialogs. Originally, we used Access Keys to provide some quick and easy functionality. However, we found in our necessity to internationalize, we were forced to completely remove the access key properties.

After all, “Done” button in one dialog could be translated to “Fin” in the French version. The original use of Ctrl-D no longer has any meaning to a French user. Thus, I consider that the need to internationalize sites and provide multiple language options also creates an issue in relation to the use of Access Keys.

(I’m only replying to this now as I’ve come across this post from one of Derek’s articles mentioned above.)