a) They are device dependent. Not all devices have keyboards in the traditional sense; Tablet PCs and mobile browsers are two such examples.

b) Access keys are counterproductive, since authors are free to specify them for whatever they want: One author may use “S” for “Search”, while another author may use “S” for something entirely different.

c) The specification is broken: Instead access keys should have been a standard set of access methods. <input type=”text” access=”search” /> would have been so much better: A keyboard-less device could have implemented it’s own access method for this, such as a pen-gesture on a tablet device, or a standard key on a mobile device, such as a phone.

I have a more extensive writeup on Accesskeys needs replacing

I don’t recommend people to not use them, but the advantages of implementing them seem non-existent compared to the time it takes. I can see them being usefull, but the simple fact that there is no standard disallowing authors to assign any key they want, I just am not sure if I’ll ever bother learning access keys for each website.

It’s probably even worse for people that seriously need access keys. I think Opera’s implementation of showing links with specific rel attribute values in the browser’s interface is a better approach — basically Arve’s point C.

I am still in limbo here. If we’re not pushing for our own non-written standard of access keys by implementing them, will it ever get better? Whenever I implement access keys, I will stick to Richard’s list though.

I havn’t found accesskeys to be very helpful within standard document web pages but for web-based applications I find the case to be A, I find them useful and my web applications usrs tell me they find them useful.

One of my favorite examples is that I added some accesskeys to an existing bulletin board system and with fast-reply and some focus() magic I made replying to a topic a 3 step keyboard-only affair. 1) alt+f (open fast reply and focus the textarea) 2) type your reply 3) alt+s (submit)

You can provide a fallback for graphics so non-graphical user agents can still understand the page. You can not provide a fallback for the ACCESSKEY attribute so they are harmful. The ACCESS attribute is set up in a way that is more logical. It does not depend on keys, it lets the author specify certain labels on which the UA could act.

On devices that do not have a built-in or attached keyboard, there is often an alternate method for connecting a keyboard to the device for the purpose of generating text or an internal method for generating text. Allowing control via the “keyboard interface” means that the content could be controlled through commands issued from the keyboard or by alternate methods that are capable of generating text as if a keyboard had been used.

It’s a shame, really, since access-keys in a more “standardized” form might provide quick and accessible navigation. They worked really well — isolated, but those conflicts creates too many problems in too many cases.

1) If these devices are have handwriting input you can use a shortcut gesture (usually one is built-in) and then the value of the accesskey.
2) Build a jump menu. Search the document for accesskeys and then build a drop-down menu of shortcuts that act just like inputing the accesskey from a keyboard. Pull the title for the menu item either from the tag value (label, links) or from the value attribute for submit and button inputs. This is where a better spec for user agents could help because then title attributes could have priority over other labels for accesskeys.
3) Phones, accesskeys with numbers are instantly handy but they also allow text input from the buttons. Letters take a moment longer to input but can still be handy on frequently used links or actions.
4) Voice input, “Access A”.

The point is that “accesskeys” has “keyboard” as a prerequisite, and any alternate means you create to access whatever is referenced, it’s a horrible, horrible kludge.

It’s even a horrible kludge on devices with keyboards:

a) There is no “standard” access key for anything
b) They conflict in translated versions of software
c) There is no visible means of listing used access keys in browsers, so the user is dependent of styling to discover them.

In a desktop context, I am predominantly a keyboard user, and I can’t honestly remember the last time I used accesskeys on a site, even where I knew they were present, and what they were. Using Opera’s built-in keyboard navigation is faster, plus it’s consistent across every site.

What I’m saying is that, despite its failings, accesskeys can be useful now and I will continue to use them because the feedback I’ve gotten on including them in web applications has only been positive. A.

We honestly have no idea if people use them or not, but no one has ever complained that we DO use them.

Access key 1 - Home page
Access key 2 - Skip to content
Access key 4 - Set focus to Search Box if available
Access key 0 - Help / Accessibility statement

completely avoid using letter, not to riskoverriding/conflicting with browser/OS shortcuts.

clearly advertise these accesskey definitions on the site’s accessibility statement.

possibly back these accesskeys up with relevant LINK elements.

i’ve had a few positive comments from users coming to www.salford.ac.uk … and i personally find myself using them when i’m on a laptop.

Mike

I have no idea if they are being used, but then again I have no idea if any of my accessibility features are. As it is I’d say that somewhere between 99.99-100% of my sites’ visitors have everything enabled and are fully capable of accessing nearly any site out there, but it’s not about who can, it’s about not barring the sometimes rare visitor who can’t.

So I offer them.

Mike

Personally I love keyboard shortcuts, as I use a laptop full-time. As a sighted person, I can’t comment on how useful they are. However, I think I would actually use access keys, provided I knew what they were. There are 2 ways of doing this.

1) A global standard.
2) Displaying access keys on links, perhaps with ?

We partially support access keys to the UK government standard:
0 - accessibility page
1 - home
4 - search
S - content

If we had a sitemap that would be there too.

Convienient additions:
N - navigation
T - top of page

I personally believe access keys are mostly used by ourselves and not the intended audience.

Agree, it’s important not to spray keys all over the site. No more than 10 could ever be considered helpful. IMHO, the UK government shortcuts should be used by all sites in the absence of leadership from anyone else. These use only numerals to minimise (not avoid) the conflicts plus the S key for skip navigation. They only go to common, key destinations on the site such as home, about us, contact, access key definitions and so on. This is good and useful functionality in my view.

I am of the opinion that accesskey is an appropriate feature of HTML - the fact that some clients have no keyboards is irrelevant; most client devices do, and there is no negative impact on the devices that do not have keyboards. Sure, it could have been done differently; what couldn’t?