Summary

Access keys are a contentious issue for web accessibility. Access keys offer a convenient mechanism for people with mobility problems to navigate their way around a website. However, access keys are notorious for causing conflicts with user agent shortcuts, and also suffer from being hidden from the people who need them. The Access Key Companion is a bookmarklet intended to make access keys easier to use, with an option to remove them if they cause conflicts with user agents.

For those of you that are impatient (too busy to read a long report), you can try the bookmarklet out before reading the full report.

Author: Gez Lemon

Contents

Access Keys

I received an email from Grant Broome, Web Accessibility Manager for CDSM Interactive Solutions Limited, about being able to turn access keys on and off to avoid conflicts with browser shortcut keys. Discussing the idea further, we came up with the idea of providing a means of making access keys more useful, as well as a means of disabling them should they cause conflicts with user agents.

Access keys are a contentious area of web accessibility. There are essentially two major problems:

The Web Accessibility Initiative (WAI) provide three sets of guidelines to aid accessibility: Web Content Accessibility Guidelines (WCAG), aimed at content developers to ensure their documents are accessible to people with disabilities and works with assistive technology; User Agent Accessibility Guidelines (UAAG), aimed at browser and assistive technology manufacturers to ensure their products are accessible to people with disabilities; and Authoring Tool Accessibility Guidelines (ATAG), aimed at developers of tools that produce markup, ranging from simple WYSIWYG editors to full-blown content management systems, to ensure the output generated is accessible to people with disabilities, as well as ensuring the tool itself is accessible.

Access Key Conflicts

The cause of access key conflicts can be found under checkpoint 6.7 of UAAG: Conventional keyboard APIs.

  1. Implement APIs for the keyboard as follows:

The contentious part of this checkpoint is, Follow operating environment conventions. If the convention for a shortcut key in Firefox running under the Windows operating system is to use the Alt key followed by the key to activate the shortcut, then according to this checkpoint, it follows that the same method should be used to activate access keys defined by the author. For example, the Windows version of Firefox has a shortcut key to access the File menu option. Pressing and holding down the Alt key at the same time as pressing F on the keyboard will cause the menu bar to open with the File option displayed. If an author defines an access key of F in the document, the access key will override the browser's shortcut. For example, supposing an author provides an access key for a link to frequently asked questions:

<a href="faq.html" accesskey="F">frequently asked questions</a>

A visitor to that page may be surprised when they try to gain access to the Firefox File menu, and suddenly end up on a frequently asked questions page instead. This is a serious usability problem.

Opera Software get around the problem of keyboard shortcut conflicts by using a different sequence of keystrokes to activate access keys than those used to activate their own shortcuts. For example, in Opera under the Windows operating system, keyboard shortcuts for the browser are activated with Alt followed by the key to activate the shortcut. In Opera, access keys are activated by simultaneously holding down the Shift, followed by Esc, and then the key required to activate the access key. Access keys are useful for people with mobility difficulties. It's ironic that a feature aimed at people with mobility problems requires a level of dexterity that requires being able to hold down three separate keys simultaneously, although operating system accessibility features such as "sticky keys" help overcome this particular problem. Thank you to Chaals, for pointing out that Opera's access key implementation works as a sticky key, which makes far more sense. Chaals also points out that the key assignments in Opera can be changed through the preferences menu: preferences -> advanced -> shortcuts, whereby you can choose your own key to activate access keys.

To my mind, UAAG is incorrect in recommending that access keys should be implemented following operating environment conventions, as the problem of conflicts is inevitable. Access keys should be implemented differently to typical keyboard shortcuts, but be activated by a single-key followed by the key to activate the shortcut.

Consistency of Access Keys

Checkpoint 9.5 of WCAG 1.0 requires authors to provide keyboard shortcuts for important links, form controls, and groups of form controls, and suggest the accesskey attribute in HTML as a means of providing the shortcut. As well as the possibility of shortcut conflicts with the user agent, there is also the issue of exposing the access key shortcuts to the visitor. Without them being exposed, visitors have to learn the access keys for each website they visit. That's not a realistic expectation, resulting in access keys not being used to their full potential.

To help get around this problem, the UK government suggest a set of access key assignments, so that at least people visiting UK public sector websites have some consistency in activating them. The following is the list of access key assignments as part of the e-Government Interoperability Framework (e-GIF) recommendations:

  • 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

Most people agree that the concept of access keys could be extremely useful for people with mobility problems. Unfortunately, the problems associated with access keys make them practically useless in reality. In writing the access key companion, I've tried to offer a mechanism to make access keys more usable, as well as provide a means of removing them if they clash with the user agent's short cut keys.

Access Key Companion Bookmarklet

A bookmarklet, sometimes referred to as a favelet, is a small script that is saved to the visitor's browser in the form of a bookmark. Traditional bookmarks store the URL for a web page, so that when the bookmark is selected, the visitor is taken to that page. A bookmarklet can be extended to execute commands on the current web page. This bookmarklet investigates the current document for any access keys. If access keys are found, they are revealed as a list of links, with an extra option to remove them.

To install the access key companion bookmarklet, bookmark the following link, or drag and drop the link onto your bookmarks/favourites toolbar.

Once you have added the Access key companion to your bookmarks/favorites, each time you visit a new web page you can activate the bookmarklet by selecting it in your bookmarks/favorites folder or toolbar.

In IE 6.0, running under Windows XP, you may have to add this page to your trusted sites for the bookmarklet to work. If you have problems installing this bookmarklet in IE, try the following:

Using Access Keys

Invoking access keys is dependent on the user-agent and the operating system. Under windows and Linux operating systems, access keys are generally invoked using Alt followed the by the access key. For example, to activate an access key of 1, press the Alt key at the same time as pressing the digit 1. Access keys in IE merely give focus to the element. For example, activating an access key assigned to a link will give focus to the link. To follow the link requires pressing the Enter key to complete the operation in IE. In all other browsers, the access keys are executed without having to press Enter. For opera running under windows, access keys are invoked by pressing Shift, followed by Esc, and then the access key simultaneously. For example, to activate an access key of 1, press the Shift key, then escape key, and then the digit 1. Opera's access key implementation appears to be buggy, and sometimes won't work as expected.

Thank you to Chaals for pointing out that the key assignments in Opera can be changed through the preferences menu: preferences -> advanced -> shortcuts, whereby you can choose your own key to activate access keys.

Apple doesn't have an Alt key, and uses the Cmd key instead. For example, to activate an access key of 1 for Safari and Mozilla on an Apple, press the Cmd key at the same time as pressing the digit 1. The exception is Opera, which uses the combination Shift, Esc, and the access key on all operating systems.

Update for using Access Keys on a Mac

Thank you to Roger Johansson for explaining how access keys work on a Mac.

Macs do have an Alt key, but it's often referred to as the Option key. As for activating access keys in Mac browsers (except Opera), you use the Ctrl key, not the Cmd key.

Limitations of the Access Key Companion

The access key companion hasn't been tested in Safari. Internet Explorer can only handle up to 508 characters in the URL. For this reason, the main functionality for the bookmarklet is stored on Juicy Studio's web server, meaning that to use the access key companion requires an internet connection. Safari sometimes has problems with hosted bookmarklets. If this turns out to be the case, I will provide an alternative bookmarklet that can be used offline, and should work with Safari.

The bookmarklet doesn't work at all in Opera with documents served as application/xhtml+xml. I'm using the appropriate DOM methods for a MIME type of application/xhtml+xml, but Opera seems to trip up when the appendChild method is used on the head element for this MIME type. If I explicitly move the script to the head of an XHTML document served as application/xhtml+xml, the script works as expected. The problem only seems to occur when trying to add the script through the URL. I even tried creating a completely separate method that only uses XHTML DOM methods, including getElementsByTagNameNS, but it still wouldn't work, tripping up on the appendChild method. I strongly suspect it's a bug (feature?) with Opera, but if anyone knows differently, I would be very pleased to hear the reason. The script works fine in Opera when served as text/html, and Mozilla/Firefox when served as application/xhtml+xml or text/html.

Access keys are traditionally applied to anchors (the a element), or the label element for form controls. This tool will use the label or the link phrase to identify what the access key applies to. If an access key is applied directly to a form control, this tool will attempt to find a title attribute for the description. If no title attribute is found, it will attempt to find the value attribute. If a title attribute and a value attribute are not provided for form controls containing the accesskey attribute, the tool will report the access key as being "unknown".

The removal of access keys physically removes the accesskey attribute from the DOM. For links and labels, that means the access keys no longer work. If an access key is provided directly to a form control, the access key will still work after being removed from the DOM, even though it can no longer be found in the DOM. This appears to be an implementation issue that is out of my control.

Category: Accessibility.

Comments

  1. [access-key-companion.php#comment1]

    Hi Gez,

    With some versions of Opera there is a bug using accesskeys that have a number as a value. (I realise this is particularly unfortunate in the context of the UK government giudelines...)

    You don't have to press the keys simultaneously - they work as a sticky key. Further, you can change the activator. I hurt my hand recently, so started using acccesskeys seriously. I use slash as the activation key instead (it is in preferences -> advanced -> shortcuts.

    I'll also ask someone who is better at Javascript than me to look into why it behaves like it does on Opera...

    cheers

    Chaals
    --
    chaals@opera.com

    Posted by Chaals on

  2. [access-key-companion.php#comment2]

    Hi Chaals,

    Thank you, that's excellent feedack. I shall update the article, as that's important to know.

    Best regards,

    Posted by Gez on

  3. [access-key-companion.php#comment3]

    An alternative way to sniff for XML is to look for document.xmlVersion, it returns "1.0" for XML and null for anything else.

    I believe getElementsByTagNameNS() doesn't work in Opera.

    I wish there was a native way to disable accesskeys in Firefox. You can get Firefox to focus instead of activate (just like IE) when using accesskeys by setting "accessibility.accesskeycausesactivation" to "false" in about:config.

    Thanks for the bookmarklet. *smile*

    Posted by zcorpan on

  4. [access-key-companion.php#comment4]

    Hi zcorpan,

    An alternative way to sniff for XML is to look for document.xmlVersion, it returns "1.0" for XML and null for anything else.

    Thank you, that's really useful to know. I came across the problem a while back, and spent ages trying to find out how to discover the MIME type, but couldn't work it out. It then occured to me that text/html is always stored in the DOM in uppercase, and application/xhtml+xml is always stored in the DOM in lowercase, so used that. It's obvioulsy better to use the correct method, so thank you *smile*

    I believe getElementsByTagNameNS() doesn't work in Opera.

    The current version doesn't use getElementsByTagNameNS, because I've tried to minimalise XML DOM methods for backwards compatibility with early browsers that understand application/xhtml+xml. I tried that method in desperation, but it still didn't work. The only XML DOM method used is createElementNS. Opera definitely implements that correctly for XML documents, and won't use createElement with XML. Firefox seems happy with just about anything *smile*

    I wish there was a native way to disable accesskeys in Firefox. You can get Firefox to focus instead of activate (just like IE) when using accesskeys by setting "accessibility.accesskeycausesactivation" to "false" in about:config.

    Again, that's really useful to know; thank you *smile* I agree about a native method to disable access keys in Firefox. It would be great if all user-agents offered a means of natively revealing them, activating them without conflicts, and disabling them. Opera definitely seems to have the most sensible aproach to access keys, it's just a shame that the implementation is slightly buggy.

    Thanks for the bookmarklet. *smile*

    You're welcome. Thank you for the useful information.

    Posted by Gez on

  5. [access-key-companion.php#comment5]

    Gez,

    On general, a balanced reporting of the issues surrounding accesskeys. One point you failed to mention is that because of the real issues and problems caused by this attribute, the W3C is deprecating "accesskey" in the latest draft of XHTML 2.

    So while some will continue to advocate the use of accesskeys, I continue to suggest that web developers should simply not bother - they're broken and even the W3C seems to concur.

    Cheers!

    JF

    Posted by John Foliot on

  6. [access-key-companion.php#comment6]

    Thanks Gez for taking the idea and running with it.

    I was hoping to get a post in before John Foliot, but he beat me to it!

    Despite John's protestations (is that a real word?), he helped me come up with the idea of access key toggling during one of the countless debates that we had. Gez has taken the idea a step further with this bookmarklet.

    I'm glad to see that Chaals provides us with a real world scenario of access key use. I'm sure that others will also find this neat little application useful.

    All the best,

    Posted by Grant Broome on

  7. [access-key-companion.php#comment7]

    "Apple doesn't have an Alt key, and uses the Cmd key instead. For example, to activate an access key of 1 for Safari and Mozilla on an Apple, press the Cmd key at the same time as pressing the digit 1."

    Hi Gez. A couple of notes on how access keys work on Macs. Macs do have an Alt key, but it's often referred to as the Option key. As for activating access keys in Mac browsers (except Opera), you use the Ctrl key, not the Cmd key.

    Posted by Roger Johansson on

  8. [access-key-companion.php#comment8]

    Thank you for explaining how access keys work on the Mac, Roger. I've updated the article with the correct information.

    Posted by Gez on

  9. [access-key-companion.php#comment9]

    Yes, it seems that the script triggers a bug in Opera. We will fix it, and I'll let you know when the fix is included in a release version.

    Although because we don't have a conflict with any keys, and because we implement accesskey by pass-through, I am not sure how much value the script provides to Opera users.

    It would be useful (JF and I have written on this elsewhere) to be able to remap accesskeys on the basis of their function - indeed that's why link elements are cool, or even rel attributes in normal links. (You can now get those recognised by the page navigation bar in Opera or Mozilla using the rel-to-link userJS, thanks to Tarquin.) So accesskeys are really only used for functions that are unusual, and the interface for search is consistent within a browser or user-configured environment...

    At which point they are indeed useful, despite what JF says, especially with the aid of something that makes sure they are available, and tells you what they are.

    cheers

    Chaals

    Posted by Chaals on

  10. [access-key-companion.php#comment10]

    Hi Chaals,

    Thank you for the update regarding the script with Opera.

    Although because we don't have a conflict with any keys, and because we implement accesskey by pass-through, I am not sure how much value the script provides to Opera users.

    There would certainly be no reason for Opera users to disable accesskeys, but the script sill offers a convenient method of exposing which accesskeys have been defined.

    I wasn't sure what you mean by imeplenting accesskeys by pass-through, so looked it up. In doing so, I stumbled across a brilliant response from Gregory J. Rosmaita on the W3C's user-agent mailing list that descibes how to make access keys useful. As far as I'm aware, only Opera have implemented access keys following Gregory's suggestion. It's great that Opera has implemented accesskeys so that they're useful, but I really hope the other major user-agent manufacturers follow suit.

    Thank you also for the heads up about the rel-to-link userJS script. I've been thinking for a while that a script would be useful to reveal link elements for user-agents that don't provide a navigation-bar. This has motivated me to do something about it.

    Cheers,

    Posted by Gez on

  11. [access-key-companion.php#comment11]

    I did backflips after reading the article, bookmarking your Access Key Companion and then seeing our access keys at the Talking Hands section. Loathing point and click as I do and with CTS and poor eye sight, Access Keys when first mentioned years ago were quickly implemented.

    Great work as usual and found another useful tool created in your workshop during my regular weekly visits to Juicy Studio.

    Posted by Denny Lancaster on

  12. [access-key-companion.php#comment12]

    I have a concern when hearing that the W3C will be deprecating the accesskey attribute. In all the discussion here and elsewhere the focus has been on desktops/keyboards. I haven't seen any consideration of its use with mobile devices, specifically phones.

    I'm currently working on a mobile site for the University of Texas at Austin (mobile.utexas.edu). It's still in beta, but we've found that access keys are extremely useful. Deprecation of the attribute would make the site less usable.

    Has anyone else been thinking about this for mobile devices?

    Thanks,
    Lewis

    Posted by Lewis Phillips on

  13. [access-key-companion.php#comment13]

    Hi Lewis,

    I have a concern when hearing that the W3C will be deprecating the accesskey attribute. In all the discussion here and elsewhere the focus has been on desktops/keyboards. I haven't seen any consideration of its use with mobile devices, specifically phones.

    As the web is supposed to be device independent, discussions about markup shouldn't be focused on any particular device. If the accesskey attribute is deprecated in XHTML 2.0, it will be replaced by the Role Access Module, so the functionality of access keys will still be there. As XHTML 2.0 is in draft, and not likely to be ready for a few years yet, the accesskey is a valid attribute.

    Posted by Gez on

  14. [access-key-companion.php#comment14]

    Gez, I just tested your bookmarklet in Safari, and I couldn't get it to work, either from the toolbar, or in the page.

    Obviously it doesn't work in IE5.2 on the Mac, but i don't think that is too surprising.

    Posted by Rich Pedley on

Comments are closed for this entry.