The accesskey attribute – do we still need it?

The accesskey attribute has been part of the HTML specification for over ten years and its purpose is to give keyboard users a shortcut to access a specific area of the page or to jump to a different page. In HTML5 the accesskey may be used on any element, but do web developers still need to use it?

The accesskey’s uptake within web development has been almost non-existent for three main reasons; differing shortcut values, browser and screenreader conflicts and discoverability.

Discoverability

The majority of users will never know that you’ve assigned accesskeys. Simply adding the attribute renders nothing visible to the front-end. However, JAWS will announce an item with an accesskey by saying “alt plus [whatever accesskey you specified]”, but unless you have specifically scripted a clever solution the general user won’t see that you’ve made the effort.

Here are a few ways of making the user aware of accesskeys:

How have accesskeys made it to HTML5?

Although the HTML5 spec includes a number of new items, it’s creators have had to ensure that older elements and attributes in general use will continue to function in future implementations of browsers (currently only the longdesc attribute has been dropped completely). Enough developers have implemented the accesskey for it to be included in the new spec.

The public-html mailing list discussion on the accesskey attribute showed that the biggest motivation for including accesskey in HTML5 is to ensure backwards compatibility of mobile content (Japan came up often) rather than aiding accessibility on the desktop.

Mobile web development

We’re talking WAP and WML, but in early WAP standards the user interface of accesskeys was not specified exactly enough and so was implemented differently from phone to phone:

Thinking back to the good old days of WML (yes, there were some good things about WML) the accesskey attribute was pretty universally supported, and as a developer you only had to worry about assigning keys 0-9. Sure, there were some other things to worry about, like if you had to number the list yourself, or if the browser would apply the numbers automatically on your behalf.

http://mobiforge.com

These, perhaps outdated, mobile development technologies are less thought of now that we have mobile phones with full desktop version of browsers. For the foreseeable future there will be parts of the world using older mobile technology so accesskeys will still be visible to certain groups.

An answer to the question?

There are conflicting implementations and recommendations when it comes to implementing accesskeys. Personally, I think developers should continue to add accesskeys, with caution, to new websites but understand that a small minority might encounter some problems:

If you do use accesskeys, I suggest following this attempt at a standard set of accesskeys as used by the UK government – it is almost totally numeric and the list has been widely cited in articles on the accesskey.

A combination of skip links, accesskeys and a well thought out document structure should be your goal.

Further reading

Emma Sax

Posted by Emma Sax

Uncategorized

Comments

  • Gary Miller says:
    12 August 2010 at 19:38 pm

    Thanks for an excellent, well written post on this topic.

    My 2p, FWIW, the accesskey is now totally redundant and just causes more confusion than it does good.

    Cheers!

  • Andy Bryant says:
    23 August 2010 at 10:14 am

    Thanks for the post. I used to work in UK local government, and while there was indeed an attempt to adopt a set of standard accesskeys on gov sites, it wasn’t universally adopted. Unless something like this is 100% adopted, so a user feels confident that no matter what site they are on they can always use the same shortcut commands, then it’s of little value in my opinion. If a user has to learn a new set of accesskeys for each site they visit, then it has the potential to do more harm than good.

    I tend to agree with Gary, accesskeys – much like tabindex – can cause more confusion than it’s worth.

  • Some links for light reading (14/10/10) | Max Design says:
    14 October 2010 at 12:31 pm

    […] The accesskey attribute – do we still need it? […]

  • Friday Focus 10/15/10: Book Sites | Devlounge says:
    15 October 2010 at 16:06 pm

    […] – The accesskey attribute – do we still need it? “The accesskey’s uptake within web development has been almost non-existent for three main […]

  • James Mansfield says:
    18 October 2010 at 03:13 am

    Nice article Emma.

    Although accesskeys provide limited value to most websites we visit they do provide huge value to an important minority. Think of support staff using the same web app daily. If they didn’t have have keyboard shortcuts (through accesskeys) to help them then they would be a lot less productive.

  • Friday Focus 10/15/10: Book Sites | CSS Citadel says:
    19 October 2010 at 18:13 pm

    […] – The accesskey attribute – do we still need it? “The accesskey’s uptake within web development has been almost non-existent for three main […]

  • Andrew Downie says:
    28 October 2010 at 01:31 am

    Firstly, a pedantic correction to how Window-Eyes (correct spelling) handles (or doesn’t) accesskeys. In IE8, Window-Eyes 7.2 announces accesskeys, including those using numerals. It doesn’t, however, announce any in Firefox 3.6.

    As a screen reader user, my view is that accesskeys are potentially much more relevant to people using the keyboard than screen reader users. Screen readers offer a host of features that make trying to memorise accesskeys on various sites a less preferred option.

    It is therefore unfortunate that those who could benefit most will usually not be aware of them. Another option for alerting users to your accesskeys is to include a list in the Accessibility section of the website.

    Andrew

  • Emma says:
    28 October 2010 at 12:15 pm

    @Andrew – I’ve amended the spelling of Window-Eyes! Thanks for the update on how it announces accesskeys.

Comments are currently closed