One of my goals for Clagnut is to make it accessible beyond good alt tags and valid code. It currently passes WCAG 1.0 Priority 1 and Section 508. To achieve this, a skip navigation link (skip nav) is required. To make skip nav (and other essential navigation) more effective, we should provide keyboard shortcuts through the accesskey attribute. For example:
<a href="#content" accesskey="2">skip nav</a>
This allows visitors to press ALT+2 or CTRL+2 (on Windows and Macs respectively) to move focus straight to the anchor in question. Keyboard shortcuts can also be applied to form controls by adding accesskey attributes to input tags in the same way.
It’s also helpful to add keyboard shortcuts for other important parts of the site, such as search, help, home page and the page which lists the keyboard shortcuts. It struck me that there should be consistency in access keys across the Web. I couldn’t find any mention of standards or suggestions on the Section 508 or WAI sites, so I attempted to see if a de facto standard has been adopted none-the-less.
The UK Government provides accessibility guidelines to which all its websites should comply. These guidelines state:
| Access key | Target |
|---|---|
| S | Skip navigation |
| 1 | Home page |
| 2 | What’s new |
| 3 | Site map |
| 4 | Search |
| 5 | FAQs |
| 6 | Help |
| 7 | Complaints procedure |
| 8 | Terms and conditions |
| 9 | Feedback form |
| 0 | Access key details |
WebAIM provides similar shortcuts:
| Access key | Target |
|---|---|
| 1 | Home page |
| 2 | Skip navigation |
| 3 | Printer-friendly version |
| 4 | Search |
These almost match with the access keys used by Mark Pilgrim (accessibility evangelist):
| Access key | Target |
|---|---|
| 1 | Home page |
| 2 | Skip navigation |
| 4 | Search |
| 0 | Access key details |
And finally, the accessibility magazine Made For All (now sadly no more) uses a few different shortcuts:
| Access key | Target |
|---|---|
| 1 | Home page |
| 2 | News |
| 3 | Previous issues |
| 4 | Resources |
| 5 | About |
| 0 | Access key details |
So there’s a fair bit of overlap between sites. The use of numbers is sensible as software often uses letters for its own shortcuts, particularly for access to the command menu. Letters also make more sense when dealing with forms (think shortcuts in dialog boxes). So the main bone of contention appears to be skip nav. Here’s a few samples:
| Shortcut | Web Site |
|---|---|
| 2 | Dive Into Mark |
| 2 | Zeldman |
| 2 | WebAIM |
| 9 | Cinnamon Interactive |
| C | Clagnut |
| C | Accessify |
| S | UK Government |
The consensus of opinion from this little lot is ‘2’. I’ve made the change accordingly and added more keyboard shortcuts to other parts of the site – see the new accessibility statement. I’ve also made my DHTML site contents menu a bit more keyboard friendly by adding an onfocus event handler to display it.
Guy wrote:
Good work batman. I’ll be keeping an eagle eye over your work in this area.
Andy Budd wrote:
Hi Richard,
Nice little accesskey article. I did a talk on accessibility at a recent event in brighton which covered this very issue. If you’re interested you can download my presentation notes from the skillswap site.
You say that you need to have skip nav links for your site to achieve A rating. I’ve had a look at the various WAI checkpoints/guidelines but can’t find a mention of scip nav links in any of them. Which checkpoint are you refering to?
p.s. love the site.
Rich wrote:
Skip nav is not a requirement of WCAG(Web Content Accessibility Guidelines) at any level, but it is mentioned in Section 508:
from http://www.access-board.gov/sec508/guide/1194.22.htm#)
David Dorward wrote:
Skip Nav is covered in WCAG 13.6
http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-group-links
brandi Hayes wrote:
nice job on your journal but we need nore on like if you saw people what are they like, and how they dress.
brandi Hayes wrote:
nice job on your journal but we need nore on like if you saw people what are they like, and how they dress.
Tomas Caspers wrote:
I still don’t see the need to provide accesskeys that simply reproduce the behaviour of other elements in HTML. Link relations do a much better job here, they are consistent across sites, work in most modern browsers (or even Lynx) and provide more meaning than a random key assignment.
UK Gov’t #1 is rel=”home”, #3 is rel=”contents”, #4 is rel=”search”, #6 is rel=”help” and so on.
Heck, you can even go and make up your own, like link rel=”privacy”.
What makes it even more problematic IMHO is that even this small set of available numbers is used by some assistive tools to cover other functionalities. IBM HPR for example will read all headlines in a page when you press alt-1.
Geoff wrote:
I made a list of available access keys if anyone is interested. The problem is that various browsers have already allocated Alt+certain keys for various menus.
Reserved Keys in IE 5.5/6
F – File
E – Edit
V – View
A – Favorites
T – Tools
D – Address
H – Help
Reserved Keys in NS 7
F – File
E – Edit
V – View
G – Go
B – Bookmarks
T – Tools
H – Help
W – Window
Reserved Keys in Opera 7
F – File
E – Edit
V – View
N – Navigate
B – Bookmark
M – Mail
W – Window
H – Help
(Someone could list what the reserved keys are for Safari on Mac OS X…)
Thus the remaining available accesskey values are (at most)
`, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, -, =, [, ], /,
C, I, J, K, L, O, P, Q, R, S, U, X, Y, Z
(I wouldn’t recommend using punctuation marks)
Hope this helps someone out there – I wasn’t able to find this information freely available on the net anywhere, so I compiled it on my own.
Michael Z. wrote:
Geoff, I don’t think you really have to worry about available access keys on the Mac OS. All Mac menu commands are operated with the “command” (aka “clover” or “apple”) meta-key, possibly modified with the shift and/or option (alt) keys. Browsers that support access keys use the control key.
Safari doesn’t support access keys (yet?).
Hnrk wrote:
Use Shift+ESC in Opera to use Accesskeys, not ALT.
litsl wrote:
good effort – anything more recent on getting these things standardised?
Richard W wrote:
Just to add to the notion of menu conflicts… If fact it does not happen. The website shortcuts take priority over the browser ones, and so the site works OK without ambiguity, and to access the browser ones you can either press AND RELEASE Alt (which activates the menu) or else press F10 to bring it up…
But anyway, it looks liee these numerical standards are now becoming much more widespread… As well as UK government, sites using them, we now also have:
UK Healthcare sites,
UK Military sites,
UK Academic sites,
USA Academic sites,
Australia Government sites,
Mainland Europe Commercial sites.
Looks like other sites can start to use this scheme as well, as this would avoid a different set on every site…
Roberto Scano wrote:
Actually is not possible to define an accesskey standard due that all the keys are mapped in the different user agent.
Only three keys are free of use:
\
/
*
Tommy wrote:
If you’re concerned about internationalization, the list of available letters shrinks considerably. For instance, the ‘Edit’ menu in the Swedish version of IE is labeled ‘Redigera’, with access key Alt-R.
Various assistive software, such as screen readers, may use a large number of access keys in the application itself.
Appler wrote:
Well, it looks as though Konqueror is getting accesskeys, so these will probably end up in Safari (and Omni) before too long, and that will mean every major browser will be supporting them.
For the record, Safari uses:
File | Edit | View | History | Bookmarks | Windows | Help.
Olivier wrote:
Safari 1.2 now supports access keys, using the Control key.
David H. wrote:
Just found this site. Lovely!
To add to hnrk’s note on Opera, their documentation says use shift + Esc THEN any letter A-Z. Numeric access keys appear not to work.
(aside)the link to Mishoo’s DHTML calendar now redirects. Looks useful. Thks.(/aside)
David H wrote:
Oops! (blush)
Numeric access keys do work in Opera. Sorry for the noise.
Dominic Lüchinger wrote:
On the Site http://www.barrierefreies-webdesign.de/knowhow/accesskey/empfehlung.php is a good introduction to this theme.
One good idea is the AccessKey-Pad find on http://2bweb.de/accesskey/index.htm
John Foliot wrote:
Well gang
The debate rages on. At WATS.ca, we still advocate not using Accesskeys, for all the reasons weve always used. A recent development is one more reasons not to
Recently, a team of students from the University of Texas wrote a Firefox/Mozilla extension plus a script to enable JAWS to interact with Firefox (see: http://www.wats.ca/articles/firefoxandjaws/71)) As part of their development, they created custom keyboard shortcuts to allow the visually impaired user to cycle through the Headings on the page – Alt + 1 for <H1>, Alt + 2 for <H2>, etc. Oops
Where does this leave the UK Standard? Which should take precedence – the UK Standard or the user agent? Our postion is pretty clear.
We encourage those interested in the full story to read the numerous article we have posted at WATS.ca: http://www.wats.ca/articles/accesskey
Tom Thekathyil wrote:
Thanks for the article on intro to access keys – just discovered this after several years of running a website!
Regards.
Chris wrote:
On http://www.zwahlendesign.ch/en/node/48 exist a new accesskey php file.
Chris wrote:
New suggestion on: http://www.zwahlendesign.ch/en/node/108 (German)
Brian wrote:
I noticed that you stated that This allows visitors to press ALT+2 or CTRL+2 (on Windows and Macs respectively) to move focus straight to the anchor in question. Keyboard shortcuts can also be applied to form controls by adding accesskey attributes to input tags in the same way. Minor dicrepancy is that the Mac uses the Command (CMD) key and not the Control (CTRL) key.
Matt wrote:
Brian, he’s right. Access keys on the Mac are done using the control key.
Grant Broome wrote:
Great article.
In response to John Foliot’s comment on JAWS, and Firefox, JAWS already has a mode to cycle through headings very easily. It’s hard to see why a shortcut is required which mimics existing functionality. All I can say is that the firefox team seem to have an existing bias against access keys to begin with. Yet again, mobility impaired users are forced to take the back seat to screen reader users. The FF team have chosen to use alt + 1 despite the fact that they conflict with a published set of commonly used access keys (not just UK standard, but notably, all the key sets listed here consistently use 1 in the same way).
But in reality it’s likely that most SR readers will stick with IE, Those who get the most use out of access keys will continue to use IE or OPERA so it would be misleading to present this point as a significant issue anyway. It’s not like people don’t have a choice of browser.
Rich Pedley wrote:
I realise this is a bit late in the day, however just came across a thread with regard to firefox that raises another issue with accesskeys, and the use ‘numbers’
http://forums.mozillazine.org/viewtopic.php?t=381305