Tags:
accessibility1Add my vote for this tag definition1Add my vote for this tag usability1Add my vote for this tag create new tag
, view all tags

Access Keys, what are they?

One of the least known features of HTML is the accesskey attribute for links and forms, which allows the web designer to define keyboard shortcuts for frequently-used links or form fields. Netscape and Internet Explorer have supported accesskeys since v4, though differently. Generally, in Netscape/Mozilla Alt-[character] selects the control and activates it immediately while in Internet Explorer Alt-[character] only selects the control and the user must than tap [Enter] to activate it. More on browser quirks and fix for IE later.

Contents:

Technical Implementation

This is the easy part. For links one simply adds accesskey="x" within the a block. Example: Edit

   <a href... accesskey="d">Edit</a>

However to make this truly useful we need to provide a cue to the user that an access key exists. A widely used practice is to underline the access key. Example: Edit

   <a href... accesskey="d">E<u>d</u>it</a>

And we might as well use the title tage to add a little more info to make the meaning clear. Example: Edit (hover over the link)

<a href... accesskey="d" title="Add or modify text on this page (Alt-d)">E<u>d</u>it</a>

twiki/bin/view

You can replace the topicaction section of your favourite skin's view template with this code block $templates/view.tmpl

%TMPL:DEF{"topicaction"}%
  <a href="%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%WEB%/%TOPIC%?t=%GMTIME{"$year$month$day$hours$minutes$seconds"}%" accesskey="d" title="Edit this page">E<u>d</u>it</a>
  %TMPL:P{"sep"}% <a href="%SCRIPTURLPATH%/attach%SCRIPTSUFFIX%/%WEB%/%TOPIC%" accesskey="a" title="Upload a file to this topic"><u>A</u>ttach</a>
  %TMPL:P{"sep"}% <a href="%SCRIPTURLPATH%/search%SCRIPTSUFFIX%/%WEB%/SearchResult?scope=text&regex=on&search=%SPACEDTOPIC%%5B%5EA-Za-z%5D" accesskey="r" title="Which pages link to this one?"><u>R</u>ef-By</a>
  %TMPL:P{"sep"}% <a href="%SCRIPTURLPATH%/view%SCRIPTSUFFIX%/%WEB%/%TOPIC%?skin=print%REVARG%" accesskey="p" title="a barebones version of this page more suitable for printing"><u>P</u>rintable</a>
  %TMPL:P{"sep"}% <a href="%SCRIPTURLPATH%/rdiff%SCRIPTSUFFIX%/%WEB%/%TOPIC%" accesskey="f" title="View previous versions of this page">Di<u>f</u>fs</a> { %REVISIONS% }
  %TMPL:P{"sep"}% <a href="%SCRIPTURLPATH%/oops%SCRIPTSUFFIX%/%WEB%/%TOPIC%?template=oopsmore&param1=1.11&param2=1.11" accesskey="m" title="rename/move, change parentage, compare revisions, ..." ><u>M</u>ore</a> %TMPL:END%

When you put it all together it looks like this:
topicaction.png

twiki/bin/edit

Adding accesskeys to the Edit page is a little more complicated because they need to go in a form. For the normal save script, you can use the following in edit.twiki.tmpl

<fieldset><legend><span style="font-size: smaller;"> AccessKeys: Save [Alt-S], Preview [Alt-V], Cancel [Alt-C]</span></legend>
   <label accesskey="s" id="save">
      <input type="submit" name="action" value="Save" id="save">
   </label>
   <label accesskey="v" for="preview">
      <input type="submit" name="action" value="Preview" id="preview" />
   </label>
   <label accesskey="c" for="cancel">
      <input type="submit" name="action" value="Cancel" id="cancel" />
   </label>
</fieldset>
AccessKeys: Save [Alt-S], Preview [Alt-V], Cancel [Alt-C]

If you use the SavemultiCgiScript this works:

<fieldset><legend><span style="font-size: smaller;"> [[Plugins.SeeSkinAccessKeys ][AccessKeys]]:<span> S = Save, Q = Quiet Save, K = Checkpoint, P = Preview, C = Cancel</span></legend>
   <label accesskey="s" id="save">
      <input type="submit" name="action" value="Save" id="save">
   </label>
   <label accesskey="q" for="quietsave">
      <input type="submit" name="action" value="QuietSave" id="quietsave" />
   </label>
   <label accesskey="k" for="checkpoint">
      <input type="submit" name="action" value="Checkpoint" id="checkpoint" />
   </label>
   <label accesskey="p" for="preview">
      <input type="submit" name="action" value="Preview" id="preview" />
   </label>
   <label accesskey="c" for="cancel">
      <input type="submit" name="action" value="Cancel" id="cancel" />
   </label>
</fieldset>
AccessKeys: S = Save, Q = Quiet Save, K = Checkpoint, P = Preview, C = Cancel

A drawback to this approach is that the fieldset legend will not wrap to a smaller screen width.

A better implementation would be to use BUTTON instead of INPUT, which allows one to use different text for the button face (what the user sees) from the value attribute (what is passed to the script). Example: .

FIX WANTED: Using button works perfectly in Mozilla and not at all in Internet Explorer. It looks right in the browser but IE submits 'Pre<u>v</u>iew' instead of 'Preview'.

Alternate approach

Use an ORDERED list for primary navigation. Then map the access keys to match the numbers of the ordered list. This has the benefit of sidestepping the whole issue of how to display the access key. -- Simon Jessey http://www.alistapart.com/stories/accesskeys/discuss/#ala-1928

the bulk of the parent story deals with several different ways of displaying access keys, all of which involve some level of contortion in either the html or css.

Which key assignments?

This is the hard nearly impossible part. This thread on w3.org indicates the quest for standard key assignments is hopelessly messy. I think the best we can strive to do is make them internally consistant and hope that there can be one single standardized accesskey: the one which takes you to the page which lists that site's access keys. It doesn't look like even this is going to be possible www wide. However at least we should be able to do so within the twiki community.

A fairly lengthy discussion on what access keys we should use for TWiki was held, but we didn't arrive at any real solution. That discussion has been refactored out of this topic in the interests of legibility. If you are curious about the removed content, read revision 1.24.

To cut to the chase: If we iron out the keys that are occupied by default in English installations of either Mozilla or MSIE, we are left with the following access keys: c, d, i, j, k, l, m, n, o, p, r, s, w, x, y and z

...I'm going to spare you the agony of different keymappings in localized browsers: Opera's implementation of keyboard interaction and access keys make the available list short enough: i, m, n, o and w

-- paraphrased from http://www.virtuelvis.com/archives/86.html

Caveats and Browser Quirks

The accesskey attribute is currently supported by the following web browsers:

  • Internet Explorer 4+ (Windows) 5+ (Mac)
  • Mozilla (Windows + Linux)
  • Netscape 6+ (Windows)
  • Opera 7 (Windows + Linux)
  • Konqueror 3.5.5 (Linux) - press & release the CTRL key, then press the access key. It also creates a number of other possible access keys on the fly and displays them in black-bordered yellow boxes.
  • Safari & Omniweb (Mac OS X) - supposedly press & release the CTRL key, then press the access key. Would somebody with access to these systems please try this and document it? For Safari on MacOS 10.5.5, you press ctrl+access key simultaneously. Press/release ctrl then key just inserts the key. Also, the choice of keys is very inconvenient for people used to using Emacs editing keys in text fields on the mac -- ctrl-p, ctrl-k, ctrl-a, etc. just do the wrong thing... -- VivekKhera - 18 Sep 2008

Other web browsers including Camino & Galeon have otherwise excellent support for web standards, but have yet to include this W3C-recommended feature.

(Konqueror/Safari/Omniweb info) -- DanStieneke - 14 Dec 2007

Key Conflicts

The following refers to English installations on MS Windows, other languages and platforms may differ.

Mozilla, Netscape and Internet Explorer all allow the access keys to override the program defaults. To use the browsers short cut key instead, press and release the Alt key, then press the shortcut key. E.g. instead af [Alt-F] to bring up the file menu do [Alt] [F].

In Opera the program takes precedence -- conflicting access keys won't work, [Alt-F] always brings up the File menu.

Many Windows users with disabilities that limit their use of the keyboard and mouse will navigate using the StickyKeys utility. It "holds down" the control keys with a single press so that shortcut combinations can be typed with one finger (or a pencil or mouthstick, etc.).

The article points out that accesskeys override Internet Explorer's predefined shortcuts and suggests that they can still be used by pressing the ALT key first and then pressing the shortcut character.

If you're using StickyKeys, pressing the ALT key first has the same effect as holding it down while pressing the shortcut character, so you still can't activate the predefined shortcut.

StickyKey users can access some predefined shortcuts by pressing F10 (instead of ALT) before pressing the shortcut character. Unfortunately this method is probably known only to more experienced users and only works for selecting menu items (F10 followed by F selects the File menu).

For example, F10 followed by D will not activate the shortcut to highlight text in the Address bar if the site uses D as an accesskey.

-- Guy M. Fisher - http://www.alistapart.com/stories/accesskeys/discuss/3/#ala-1977

Internet Explorer

With Internet Explorer, the user has to press Alt-N followed by Enter rather than just Alt-N as is the case with Mozilla & Opera. To make things more confusing, buttons with accesskeys do activate immediately.

Fortunately there is a workaround:

There's a better, more transparent way (and certainly less time consuming) to make accesskey links in IE auto-link with focus. [...] the process should be make to trip only when the ALT key is pressed congruently with a focus trigger.

Now, since we only want this for IE, we can use a DHTML behavior to trasparently and easily add this functionality to our links. First, add this to your css

a { behavior: url(misc.htc) }

Then, create the HTC file

<public:component>
<public:attach event="onfocus" onevent="focusHandler()">

<script language="JScript">
function focusHandler()
{
if ( element.accessKey && event.altKey )
{
element.click();
}
}
</script>
</public:component>

That's it! You don't have to touch the HTML of EVERY SINGLE link. -- Peter Bailey, http://www.alistapart.com/stories/accesskeys/discuss/3/#ala-1996

Resources

Terminology:

An access key is an alphanumeric key - sometimes referred to as a mnemonic - that, when used in combination with the ALT key, navigates to and activates a control. The access key matches one of the characters in the text label of the control.

Shortcut keys (also referred to as accelerator keys) are keys or key combinations that users can press for quick access to actions they perform frequently. CTRL+letter combinations and function keys (F1 through F12) are usually the best choices for shortcut keys. By definition, a shortcut key is the keyboard equivalent of functionality that is supported adequately elsewhere in the interface.

-- MS Developers Network

Links:

  • http://labs.google.com/keys/index.html - Once again the people at Google Labs take a simple idea and do it very well. Their approach is to use javascript to build in-page keyboard navigation. It doesn't require adding "accesskey=x" attributes to every link.


Existing "Standards"

While there are no standards for which keys should be assigned to which features, here are some commonly-used keyboard shortcuts:

Access key 1 Home page
Access key 2 Skip to main content (the navigation bar skip link)
Access key 4 Search box
Access key 9 Feedback
-- http://diveintomark.org/archives/2002/06/28.html
which links to the excellent overview paper http://www.cs.tut.fi/~jkorpela/forms/accesskey.html

The WebAIM (Web Accessibility In Mind) site uses the following assignments:

1 home page (i.e., main page of site)
2 skip navigation (i.e., location after navigational links at the start of page)
3 printer version
4 index/search

The Guidelines for UK Government websites contain a section on accesskeys: UK Government accesskeys standard:

S skip navigation
1 home page
2 what's new page
3 site map
4 to the search facility on the site
5 frequently asked questions (F A Qs)
6 help page/facility
7 complaints procedure
8 terms and conditions (including privacy statement)
9 feedback page
0 the menu page of accesskeys detailing the accesskeys are being used within the website and the information or services they link to.


ThreadMode comments & discussion

Older discussion

Great idea! One of the major usability problems in web interfaces is that the keyboard becomes virtually useless, thus increasing mousing strain. Taking advantage of the useful but unknown AccessKeys would help a lot. I also like the idea of using digits as suggested for common navigation and character keys for other items.

But with regard to the numbers of operating systems, browsers and languages, I doubt if any universal key assignments can be found. [...]

I also added other assignments and comments above, mostly based on what "rhymes" with key or number usage in other programs or systems. Rhyming is important because it helps people remember it.

With regard to non-letter non-digit access keys ( ? / > ... ), consider that many of them are shift-key characters on many non-English keyboards and maybe not usable as access keys.

-- TorbenGB - 03 Jul 2002

[...] Unfortunately there does not seem to be an easy/clean way to use the same techniques on % WEBTOPICLIST% or % WIKIWEBLIST%. The only approach I can think of requires using html instead of WikiWords. eg: <a href="/% WEB%/% HOMETOPIC%" title="the front page of this web" accesskey="1"> instead of [ [% HOMETOPIC%][Home]].

-- MattWilkie

[...]

Update: I could make it work, nice feature indeed. However, I think ALT+letter is more intuitive than ALT+number, this is what I am toying with with the current KoalaSkin: (see it live at http://koala.ilog.fr/wiki )
In the main view, pressing ALT and a key does:

  • t Top, goes t(o the root home page of the site
  • e Edit, edits the page
  • a Attach, attch a document
  • n New, create a new topic
  • s Sitemap, go to the site map
  • h Home, goes to the WebHome of current web
  • c Changes, goes to the changes pages
  • i Index, goes to the index (lits of topics, alphabetical)
  • f Find, goes to the search page
  • p Printable, switch to printable skin
  • r Raw, switch to Raw view
  • d Diffs, see diffs
  • m More, goes to the More page (move/rename/delete/reparent...)
In edit and preview view:
  • s Saves
  • q Quietsaves
  • c Checkpoints
  • p Preview mode (in preview, goes back to edit mode)
  • z (undo) Cancels
  • r toggles Release edit lock checkbox
  • m toggles Minor changes checkbox

-- ColasNahaboo - 13 Dec 2002

[...] I agree that letters are better than numbers, however it is difficult to find ones which aren't already used by something else. For example Alt-e is used by most programs to bring down the Edit menu. Access keys in web pages take precedence, in current browsers, so a user pressing Alt-e will get unexpected behaviour (a new web page rather than the contents of the Edit menu). Note: the menu does still work with Alt , e (press and release Alt key, then press E).

[...]

So in the end what is effective will be determined by your users (e.g. if accessiblity is not an issue you don't have to worry about using up keys used by screen readers).

-- MattWilkie - 13 Dec 2002

Yes. By asking developers using TWiki, none used the ALT- browser keyboard shortcuts, but they used the CTRL- ones, so it did not seem to conflict. I saw some that used the ALT-number to zoom the fonts, however. I will test it with non-techies (assistants, marketers). But of course, I have made this optional in the KoalaSkin (you can disable them by setting a variable, I will see if I can add a setting to use numbers instead). Too bad the bindings are not part of CSS, that should be definitely something that would have been logical in an user stylesheet. It really should be a per-user option, but I do not see how it could be implemented, except via a different URL to a different set of templates

But once I showed people that they could do: ALT-e edit ALT-s they were hooked on the feature (with mozilla, the need to hit enter with IE is cumbersome... and no what is specified in the W3C spec). a fix for this annoyance is above in the IE browser quirks section.

-- ColasNahaboo - 14 Dec 2002


A major top-to-bottom refactoring took place on 28 June 2003, there is a lot stuff in rev 1.24 which is no longer reflected here.

This topic borrows a lot from the A List Apart story on http://www.alistapart.com/stories/accesskeys/][Access Keys]] and ensuing discussion. Many thanks to Stuart Robinson, the author.

-- MattWilkie - 28 jun 2003


What key to list the keys?

Seeing as a set of access keys to work across all browsers and languages is impossible, I'd like to see if we can decide on which single accesskey we can all agree on should be used to link to the page (or javascript popup or whatever) which lists all the access keys used on that site. (Or web, or per-user, etc.)

Thoughts?

-- MattWilkie - 28 Jun 2003

Specific browser compatibility

Safari

I'm disappointed to find that the Twiki AccessKeys (using PatternSkin) do not seem to function for Safari (ver 1.2.2) even though all references I find indicate that they should. Some other access keys I've heard of do work, such as cntrl-1 for home. Anyone have thoughts on what might cause this?

-- LynnwoodBrown - 11 Aug 2004

Firefox 1.5+

With the new version of Firefox, released the end of November 2005, I note a accesskey semantic change in Firefox's implementation that means that the current implementation of TWiki access keys - particularly on edit - has changes. Namely the Save, Quietsave, Checkpoint, and Preview acceskeys just move focus to that button, rather than activate the button action. (Cancel is unaffected, as it is not a submit input field.)

This is because current templates use a LABEL element with the accesskey; it is not attached to the INPUT element. As such, this is a/one correct result. One needs to think about the desired semantics for your site - and the TWiki default - to see if a change is needed to your templates. If you want an immediate action on the access key press, then edit the edit template, and move the accesskey attributes from the LABEL element to the INPUT element.

-- ScottClaridge - 30 Nov 2005

I prefer direct action: press access key 'S' and the topic is saved. Just a small thing to change.

-- ArthurClemens - 30 Nov 2005

Sorry to need specific details of this, but can you give me an example ? Do I just move the acceskey="k" part or do I also move the for="checkpoint" part. If so, do I remove the <label> section altogether.

Forgive my ignorance,

-- SteveJonesST - 01 Dec 2005

For Dakar I have made this change. Yes, you have to remove the label altogether.

-- ArthurClemens - 04 Dec 2005

Internationalize the access keys

We still don't have a good way to internationalize the access keys. The button/link labels get translated, but they no longer map the actual access key. The access key is not in the pot files. Any thoughts on this?

-- ArthurClemens - 04 Dec 2005

I found a way writing msgid "value='Cancel' accesskey='c'" in the pot files. Translators must remember not to translate 'value' and 'accesskey' smile

-- ArthurClemens - 08 Dec 2005

I discovered that Firefox 2.x requires Shift+Alt+accesskey ... couldn't figure out why accesskeys weren't working after the upgrade and looked for the reason. Found info from http://juicystudio.com/article/firefox2-accesskeys.php

-- MatthewKoundakjian - 10 May 2007

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng topicaction.png r1 manage 1.9 K 2002-09-09 - 23:48 MattWilkie topic action with underlined accesskeys
Edit | Attach | Watch | Print version | History: r37 < r36 < r35 < r34 < r33 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r37 - 2008-09-18 - VivekKhera
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.