Access Key Companion

Saturday, 23rd July 2005

Author: Gez Lemon

Contents

• Access Keys
• Access Key Conflicts
• Consistency of Access Keys
• Access Key Companion Bookmarklet
• Using Access Keys
• Limitations of the Access Key Companion

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:

• They can conflict with user agent shortcuts
• There is no consistency in the way they are implemented, meaning that the user may not know what access keys have been provided.

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.

[Back to the contents]

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:

   • Follow operating environment conventions.

   • If no conventions exist, implement publicly documented APIs.

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.

[Back to the contents]

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.

[Back to the contents]

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.

• Access Key Companion

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:

• select 'Tools' from the menu bar
• select 'Internet Options' from the drop down menu
• select the 'security' tab
• select the 'Sites' command button from the dialog box
• Enter http://juicystudio.com in the text box to add to the zone
• Ensure 'Require server verification' is unchecked (you should re-check this option after adding Juicy Studio)
• Select the 'OK' command button to add Juicy Studio
• Select the 'OK' command button to finish adding trusted sites

[Back to the contents]

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.

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.

[Back to the contents]

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.

[Back to the contents]

Category: Accessibility.