techblog 

As part of our goals to make our web content as accessible as possible, we looked at (amongst other functions) the use of access keys. There are actually many differing views on the use of this capability, with divisions appearing to take on a geographic dimension. To summarise, there now appears to be a distinct North American versus European standpoint on the subject, centering on the availability or choice of available keys.

What are access keys?

Access keys are author or user-defined keys that are assigned to textual hyperlinks or specific HTML
elements (such as <input>) within a webpage. In short, a hyperlink or HTML element may have a letter or number associated with it, which when used (usually in combination with keys such as Alt or equivalent) targets that link, thus removing the need to use a mouse to navigate or (for example) select a particular field.

The access key attribute, introduced in HTML 4.0, can be written as <a xhref=”somewhere.htm” accesskey=”L”>Link Text</a>

Are access keys standardised?

Access keys are advocated by W3C’s WAI (Web Accessibility Initiative). A broad example of websites that use, or at least encourage their use, include (in no particular order):

• Most but not all UK government sites (e.g. cabinetoffice.gov.uk)
• scottish.parliament.uk
• Other international government sites.
• bbc.co.uk
• sitepoint.com (developer/accessibility resource site)
• alistapart.com (well known CSS discussion site)

However, there are many differing views on accessibility, mostly aired on various forums or CSS discussion sites. A sample of sites that do not advocate use of access keys appears below:

• nomensa.com (http://www.nomensa.com/resources/articles/accessibility-articles/access-keys.html)
• accessifyforum.com (for and against, see website)
• wats.ca, Web accessibility consulting firm (http://www.wats.ca/show.php?contentid=32)

The benefit of using access keys in my view is that it makes it easy for some people to use and navigate websites if they are unable to use a mouse, solely need to use a keyboard for whatever reason, or are for example using a screen reader. Bearing this in mind, and although they are part of the Web Accessibility Initiative defined by the W3C, it seems it is no guarantee of takeup by the developer community.

What are the issues surrounding use of access keys?

The current situation regarding take up and use of an approved system is actually fairly complex. Fo  starters, there is no approved system of which, or what, access keys to use. The list below identifies some basic issues:

1. Not every browser or version supports access keys. In addition, behaviour differs from browser to browser; IE in later versions requires use of the Enter key after using an Alt key. However, since access keys are primarily aimed at users who would in all likelihood use a screen reader, non-compatibility of some browsers (Netscape Navigator, IE4) in this respect is not a major issue.
2. Some screen readers already make use of access key combinations; these will be overridden by those defined in a web page, negating the user’s preferential Alt keys (such as ‘D’ for accessing the address bar in a browser). The worst keys to use according to some are D, E, F, and H, as these are commonly used for other functions. See http://www.wats.ca/show.php?contentid=43 for more information.There is no standard set of key definitions, and therefore every web site has their own configuration. A more standard method would be to employ numbers instead of letters (this method is used by government and the BBC) to define commonly used functions – skip to main content, search, site map and home, for example.
3. Making users aware that access keys are available requires a visual clue for the links themselves (usually underlining or emboldening), as well as, or instead of, a page of content providing information on their use. This is not a serious problem, but can impinge on content layout or presentation).

As a region, North America uses two main screen readers (namely JAWS and IBM’s HomePageReader) that come with their own access keys already defined. These two applications hav  a fairly international user base however, and so most screen reader users in other parts of the world are also likely to be using this software.

Accessibility advocates based in North America have taken a position of championing these two applications and the access keys they use, and support a move to deprecate or simply not use the W3C defined XHTML accesskey attribute as it can override the access keys defined by these top two screen readers. This alternative position also advocates replacing the XHTML attribute instead with similar elements (see http://www.wats.ca/show.php?contentid=47)

Some accessibility groups have additionally persuaded the Canadian government to drop their implementation of access keys on their websites. The approach the Canadian government took originally was the same as the UK government; namely using a series of numerals (1-6) to provide specific functionality for common tasks. With British and possibly European developers now looking to the UK government’s implementation (rightly or wrongly) as a standard (the BBC implements this approach as well), there is now a real conflict of perceived ’standards’.

W3C have also written a new attribute (“@key”) into the draft XHTML 2.0 specification, again much to the annoyance of the North American accessibility groups who see it as the same as the previous “accesskey” attribute mentioned above albeit under a different guise. Developers of the Firefox browser have also written a plug-in for the JAWS screen-reader (which previously was not compatible with Firefox) that pre-defines the access key numerals 1-6, which would also conflict with a ’standardised’ UK implementation of using numerals for common functions.

Based on the above divisions in the developer and user community, there is a a marked division on how to proceed with any standard regarding access keys. In fact it seems that there is no broad agreement as to what that standard might be; hopefully one will emerge sooner rather than later.