Accesskey problems remain in XHTML 2

The accesskey attribute sounds like a great idea at first. Being able to attach a keyboard shortcut to elements in an HTML document allows users to quickly jump to different parts of the page or trigger functionality without having to use a mouse.

The problem, as has been stated by Derek Featherstone in More reasons why we don’t use accesskeys, John Foliot in Using Accesskeys - Is it worth it?, and Jukka Korpela in Using accesskey attribute in HTML forms and links, to name a few, is that most current web browsers do not prevent shortcuts assigned through an accesskey attribute from clashing with existing keyboard shortcuts specified by the browser or operating system. Even if they did do that, there would still be issues with internationalisation and key availability.

Because of this, I rarely use the accesskey attribute. In fact, I am considering not using it at all. Looking forward (way forward), the accesskey attribute is not included in current drafts of XHTML 2, since it has been replaced by the access element. Unfortunately it looks like the access element will suffer from the same problems as the accesskey attribute.

John Foliot explains why in ACCESS + KEY still = ACCESSKEY - The XHTML Role Access Module still flawed, an open letter to the draft editors of XHTML 2. Ian Lloyd at Accessify agrees and points to a system that lets users specify their own shortcut keys in The Trouble With Accesskeys.

Posted on January 1, 2006 in Accessibility, Quicklinks, Usability

Comments

  1. January 1, 2006 by wrtlprnft

    Opera has an implementation for accesskeys that is guarrantied not to interfere with os or browser commands: You press shift-esc and then the key.

    Unfortunately, all other browsers use the alt method…

  2. The problems surrounding ‘access’ / ‘accesskey’ won’t be solved until the actual key-choices is left to browsers/visitors. There’s no way to solve it at the author-end. I stopped adding ‘accesskey’ quite a while back, after having seen what a mess one can create by using them. Doesn’t help much that I’m using Opera, since most visitors don’t :-)

    There are ways to address the need for navigation through shortcuts without resorting to ‘accesskey’. Link-relations can be used, and browser-developers can apply their own solutions/keys to those. That’s already done, in parts at least, in some browsers, and it doesn’t disturb any other shortcuts. No need for new standards, but most browsers will need an upgrade and customizing-options.

  3. I hate accesskeys. Especially any site or app that overrides Alt-D. MovableType, I’m looking at you! I use it to quickly access the address bar to type in a new URL. Too bad in MovableType it wants to delete the current post. Or sites that use it to take me to their Downloads section.

  4. Under a GNU/Linux-OS your choice of WM/DE is gigant, and every one of those lets users create and edit shortcut keys. freedesktop.org is working together with KDE and GNOME to standardize keys and such, but shortcut keys will always be irritating to some users, for instance the ones who tries to open Konqueror “alt-o” while writing a longer article on Wikipedia, but ends up being logged out and all the texts disappear.

  5. Jonathan: I’m not sure what browser you’re using, but why don’t you stick to CTRL-L which works in most browsers.

    I’m trying the best I can to not use ALT as a shortcut when I’m using a browser.

  6. It is also a huge problem in SMIL 2.1 (which is a recommendation already). But only one person cares about that… Well, a bit more than one, but you get the point.

  7. I find the Opera Shift-Escape idea really nice. If only one key combo could be universally available, a bunch of keys could actually be standardizedShift-Escape h for home page, Shift-Escape m for site map, Shift-Escape s for search, and so on. Now we’re caught in a world where accesskeys differ from site to site so even vi-oriented power keyboard users are not using the keys. No standard can be expected when you can’t even be sure the accesskey is accessible…

  8. I’m in agreement. I’m constantly getting caught by alt+s, which i use to open the sage toolbar in firefox. Instead on accesskey sites I ‘skip to content’. In principal they are a great idea, just with poor implementation.

    Also, I agree with Jonathan on the Alt+D key combo. Ctrl+L is more of a stretch, and my right hand is usually on the mouse ;)

  9. Right, that’s it. Access keys officially annoy me immensely.

    I was just on dustin diaz’s site, and I attempted to type the euro symbol from my laptop american keyboard layout which involves pressing fn + alt +0163.

    Off i go on a trip round the world. Well, round his site. As the site interperets that 1, 6 and 3 as being me wanting to navigate with access keys.

    Sorry to report that the same thing happens here. I assume there is another way, but i often use alt + (numeric keypad)0128 to get the euro symbol, and 0163 to get the pound symbol. I was just very surprised to see the result!

  10. Right, that’s it. Access keys officially annoy me immensely.

    That’s a bug in Mozilla/Firefox (and, perhaps, other browsers). fn-Alt-N ≠ Alt-N, and shouldn’t trigger the keyboard shortcut.

    I 100% agree that the keybindings for accesskeys (or the access element) should be editable by the user and, in the case of conflicts, the conflict should always be resolved in favour of the built-in keyboard shortcut.

    But Foliot’s objections to the key attribute of the access element are misguided.

    To pick one example, he argues that the suggested key-binding (having one, he says, is a good idea), rather than being an attribute to the access element, be included in the RDF document defining a custom role. This

    1. Requires the UA to download the RDF resources corresponding to each access element with a custom targetrole attribute for no other reason than to extract a single character. This is a horrible waste of bandwidth. At best, it’s a performance problem. At worst, it breaks whenever the RDF resource is hosted by a 3rd party and that site is unreachable (say, because the document is served on an intranet).
    2. If the web author is using a set of 3rd party-defined roles, it doesn’t even allow the author to resolve conflicts between the suggested keybindings for the different roles.
    3. It doesn’t even apply to access elements with targetid='foo'.
  11. And, just to emphasize the obvious:

    1)On-the-fly remapping of accesskey keybindings (as the aforementioned Javascript provides) includes disabling accesskey(s) by setting the corresponding keybinding(s) to the empty string. (John Foliot would be happy.)

    2) The same technique is readily applicable to XHTML2’s <access> element. In fact, it’s even easier, in the sense that the <access> element is “self-documenting” in a way that the current accesskey attribute is not.

  12. January 15, 2006 by Roger Johansson (Author comment)

    This site no longer uses accesskeys. I received too many complaints from visitors who were confused when their keyboard shourtcuts didn’t work.

    Jacques: All valid points. Requiring the UA to download external resources doesn’t seem like a very good idea.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.