Quiz 2.1.1: Are Access Keys Useful?
Designer Jon Hicks asks if access keys are useful? WCAG 2.1 guides us to make all functionality operable via a keyboard or keyboard interface. Personally, I like using a lot of keyboard sort cuts instead of reaching for the mouse. So, even though I don’t need them, I find access keys very convenient.
Richard Rutter has given us information about commonly used access keys over at Clagnut.
Then again, others have told us of key assignment conflicts and why they don’t use access keys.
Q. Are Access Keys Useful?
- A I include access keys and my visitors tell me they like them.
- B I include access keys, but have no idea if people find them helpful.
- C I don’t include access keys because of the key assignment conflicts.
- D I don’t see access keys as useful because…
April 15th, 2005 at 6:51 am
E) I don’t recommend that people use access keys because:
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
April 15th, 2005 at 7:12 am
I have to go with Arve here.
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.
April 15th, 2005 at 7:23 am
“Not all devices have keyboards”, that’s like saying not to use graphics because not all browsers are graphical browsers. Sure, a better standard or better recommendations for implementation for user agents could be written but that doesn’t mean they can’t be useful now.
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)
April 15th, 2005 at 8:00 am
Chris Griego, you are wrong. Markup (and especially a language like HTML, XHTML, etc.; I acknowledge it might not make sense for SVG) should be designed in a device independent way. Since the ACCESSKEY attribute is not designed in such a way, it is harmful. I think the ACCESS attribute from XHTML2 is more useful.
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.
April 15th, 2005 at 8:03 am
Before we go too far down the “devices without keyboards” path, please be aware of what WCAG 2.0 says about keyboard interfaces.
April 15th, 2005 at 8:12 am
I’ve used access-keys, and found them useful. However, the conflicts between access-keys and other shortcut-keys kept popping up in my face all the time, so I’ve stopped using access-keys.
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.
April 15th, 2005 at 10:12 am
Accesskeys provide shortcuts, here’s some examples of how the shortcuts could still be provided without keyboards.
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”.
April 15th, 2005 at 10:29 am
Chris:
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.
April 15th, 2005 at 12:29 pm
Generally C, although occasionally B. C, because in most cases they’re not automatically discoverable and conflict with browser defaults in a different way for every browser. Occasionally B, because sometime a client asks for them (in which case we usually go by the UK Government recommendations), or in one case because I was experiementing with navigation methods in a graphical tour of a building (I added WASD access keys).
April 15th, 2005 at 1:12 pm
I’m a C man, after being a B for quite a while. I don’t think I’ve read anything positive about accesskeys in the last couple of years so I just decided to ditch them. I provide skiplinks to the main content, main nav and search and leave it at that… I really like the sound of access points though - device independent, internet-wide and semantic. There was a good Derek Featherstone article from last year about this: The Future of Accesskeys.
April 15th, 2005 at 2:05 pm
Yes, “accesskey” does obviously relate to the word “keyboard”; yes it should have had been defined with different semantics and improved definitions for user agent implementations. I don’t disagree with any of that.
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.
April 15th, 2005 at 3:56 pm
In the redesigns of the sites we manage at work, we’re probably best described as B. We include them, and we include an accessibility statement outlining what our access key schema is. I personally don’t see the harm in including them. It gives one more layer to an accessibility solution.
We honestly have no idea if people use them or not, but no one has ever complained that we DO use them.
April 15th, 2005 at 6:14 pm
F) implement minimal accesskeys for the most common sections of a site, taking inspiration from UK’s governmental guidelines…usually just something like
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.
April 15th, 2005 at 7:27 pm
A, B, and C depending on the target audience for each specific project.
April 15th, 2005 at 10:05 pm
The option I’ve always gone with is B. I include some, try to keep them standard across all the sites I’ve built but really have no idea if they are useful. I never specify letters, always numbers or symbols. I completely agree that implementation of accesskey was broken in conception but my thinking corresponds with Joe Clark’s: include ‘em anyway.
April 17th, 2005 at 7:39 am
It’s B for me and we have to provide them since we are bound by the UK Government guidelines on website design. But given what I’ve been reading over the last few months I suspect I’ll start looking at the tag.
Mike
April 17th, 2005 at 6:04 pm
B on this, for now. I try to avoid conflicts by sticking to numbers.
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
April 18th, 2005 at 6:28 am
Like Mike, I’m bound to use the UK Government standards for much of my work (see http://www.hmrc.gov.uk, which went live today!).
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 ?
April 19th, 2005 at 5:04 am
Definitely B.
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.
April 19th, 2005 at 8:18 am
(c) it is annoying when alt+d, alt+a, alt+f, alt+t etc. are overriden by accesskeys.
(d) Being blind I am part of the “intended audience” but never use them. The problem is that you don’t know which key is assigned to a link until you arrive at that link.
Another issue is that it is impossible to assign accesskeys that are easy to memorize. It is obvious we should stick to numbers but I see no link between 1 and home and between 4 and search. Maybe in the future numbers aren’t safe anymore when screenreaders or other apps assign a function to alt+1 …
I am wondering how we will agree on a global standard, especially as there are only ten possible keys to define. A site without a search box would be unable to use the 4 as an accesskey etc.
April 19th, 2005 at 5:41 pm
Generally, b. But I’d have to go with redux on this one as I cannot see how more than a few accesskeys can successfully be implemented on any site.
April 26th, 2005 at 4:35 am
B/F for me - Accesskeys desperately need a global standard. This will a) encourage their use and b) mean that users don’t have to relearn different keys on different sites. The conflicts with screen readers and other AT will only be resolved once there is an established set of characters for them to avoid.
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?