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

Access keys: (still) worth the trouble?

See also: AccessKeys

We have implemented access keys as:

  1. Super user shortcut to action buttons
  2. Aid to accessiblity

Access keys have been a recommendation in Techniques for Web Content Accessibility Guidelines 1.0 (2000)

Not every user has a graphic environment with a mouse or other pointing device. Some users rely on keyboard, alternative keyboard or voice input to navigate links, activate form controls, etc. Content developers should always ensure that users may interact with a page with devices other than a pointing device. A page designed for keyboard access (in addition to mouse access) will generally be accessible to users with other input devices. What's more, designing a page for keyboard access will usually improve its overall design as well.

And while I knew there were some issues with the different key combinations on each platform (see also the complaining about the changed key handling of Firefox in FireFox2Improvements), I still had the idea this was a Worthy Goal. Also because they are so well implemented on Mac OS X, which I use.

I did a quick read up on Wikipedia:Access_keys:

In the summer of 2002, a Canadian Web Accessibility consultancy did an informal survey to see if implementing accesskeys caused issues for users of adaptive technology, especially screen reading technology used by blind and low vision users. These users require numerous keyboard shortcuts to access web pages, as "pointing and clicking" a mouse is not an option for them. Sadly, their research showed that most key stroke combinations did in fact present a conflict for one or more of these technologies, and their final recommendation was to avoid using accesskeys altogether.

The article pointed to an article by WATS.ca - web accessiblity technical services: Using Accesskeys - Is it worth it?:

So while it seems that Accesskeys is a great idea in principle, implementation brings with it the possibility that it either will not be available to all users, or that the keystroke combination encoded within the web page may conflict with a reserved keystroke combination in an adaptive technology or future user agent. This potential problem was subsequently brought to the attention of the Canadian Common Look and Feel Access Working Group (who had previously suggested the use of Accesskeys M, 1 and 2), and after consideration the Access Working Group reversed it's recommendation and now suggest not to use Accesskeys on Government of Canada Web sites.

Access keys are further burned down here:
Using accesskey attribute in HTML forms and links by Jukka K. Korpela:

The accesskey attribute, aimed at making web pages more accessible e.g. to people with motoric disabilities, has proved out to be poorly designed and poorly implemented. Although it is still endorsed by some recommendations, it tends to reduce accessibility rather than help people, though there are some special situations where it might improve useability.

One more note: access key links are a pain to translate.

Still endorsed on:

So my question is: so if we are actually making it more difficult for people, how useful are access keys to you? Should we make the step and remove them altoghether?

-- Contributors: ArthurClemens - 14 Dec 2006

Discussion

Myself, I could not survive without AccessKeys. As someone who already uses an alternative keyboard (Data Hand), access keys have become more important (not less).

-- KeithHelfrich - 15 Dec 2006

I always, always use ALT+E, ALT+S to edit and save topics and very rarely actually click the buttons. The unfortunate changes in FireFox2 are easy to workaround for power users which are probably the ones making most use of AccessKeys.

-- StephaneLenclud - 15 Dec 2006

While I am not against access-keys, Arthur already mentioned the main problem with acces-keys: "access key links are a pain to translate"

The need for translation of access-keys is only based on the appearance in the skin visual marked as an underlined character. At the moment Translation of access-keys derivate from the action: (e)dit, A(l)l Webs, (P)rint

Obviously translations using different words for actions, the result is: you have to create a consistent set of access-keys for every language! Besides that I don?t know many applications which change their access-keys for every language, I think this is simply a usability fault.

BBC and Plone use numbers, which do not need to be translated. Further on they use a different site to explain the available access-keys.

My solution would be:

  • define one set of access-keys for TWiki not for the language
  • make up an own site for their description

-- AndreUlrich - 15 Dec 2006

While I see that access key numbers are standard use on these sites, this is a usability horror. With no visual feedback users are forced to remember the key combinations for each site.

-- ArthurClemens - 15 Dec 2006

Sorry, but you pointed out those sites as an example for using access-keys smile

I think I clearly highlighted the problems with translation of access-keys. Maybe we could find some solutions?

What is the difference of an internet application and a desktop application? In the desktop application world power users also have to remember their shortcuts and noone is moaning about that. In an desktop environment there may be a standard way to get known to the available shortcuts by pressing some key. Why not provide a shortcut to call the shortcut description, like bbc and plone did by pressing the "0"-accesskey? The site could appear with some fancy AJAX effect and everyone is happy.

BTW, I find that an initial brainstorming with all that "I like xxx" and "I feel zzz" is better placed realtime on TWikiIRC with reasonable feedback. To nail down final solutions wiki is nicer.

-- AndreUlrich - 15 Dec 2006

Microsoft and Apple publish Human Interface Guidelines to provide developers with consistency guidelines. Such guidelines do not exist for web sites. Also, application menus show the shortcut when you click on the menu item. To show the hint after clicking is not possible with web links.

There are several ways to give the hint with links:

  1. Visible: using an underline under the character. This rules out numbers because no number is in de link label.
  2. Visible: using a bracket notation: Edit (1). This is cryptic.
  3. Visible after mouse rollover (and screen reader?): in a title tag. For instance Edit. Or use access key: e.

Using AJAX to show the hints: where should they appear?

Funny enough, we use Codev for discussions and IRC release meetings to nail down solutions smile

-- ArthurClemens - 15 Dec 2006

I am also not aware of an "Interface Guideline for Webapplication". I said: "In an desktop environment there may be a standard way to get known to the available shortcuts by pressing some key". This can till example be some key to open up the menu, I'm sure there are least some for Windows, Mac OS and probably for KDE on Linux.

Wouldn't it be possible to place a shortcut for the help page like Alt-H and make that link call a javascript function which opens up a fancy help bar on the screen?

-- AndreUlrich - 15 Dec 2006

A quick look told me that this of course will work:

<a href="" onclick="alert('call a fancy AJAX window for shortcuts');" accesskey="h">call a fancy AJAX window for shortcuts</a> [Alt]+[h] 

Where the window exactly does appear is up to the "usability designer". Again:

  • define one set of access-keys for TWiki not for the language
  • make up an own site for their description
  • call the shortcut window wherever you like

-- AndreUlrich - 15 Dec 2006

As far as I remember MS Windows shortcuts don't change from language to language. Ideally each registered user should be able to customize its AccessKeys.

-- StephaneLenclud - 16 Dec 2006

Access keys are important to me. I think having them the same in all languages (using the keys of the default english translation) is not a problem, it even eases support somewhat.

-- SteffenPoulsen - 19 Dec 2006

That is not possible unless you drop direct visual feedback. In that respect they cannot be compared with application menus. Access keys are currently recognized by an underline of the access key char. But if that char is not available in the translated link text, where would the underline go?

  • In the danish translation I simply used something like "Vedhæft (&A)" for "Attach". -- SteffenPoulsen - 19 Dec 2006

-- ArthurClemens - 19 Dec 2006

@Arthur: Where is the problem in dropping so called "direct visual feedback"? Why do you think the solution I suggested is not feasible?

-- AndreUlrich - 19 Dec 2006

This is an interesting issue. Donald Norman has a chapter about it in The Design of Everyday Things, called "Knowledge in the head and in the world". Essentially, information that is not in view has to be memorized. It requires learning, or finding/memorizing the place to get access to the needed information. So it provides less ease of use at first encounter. And I would say less ease of use even with repeated encounters.

Remember the BBC page about access keys mentioned above? Now go to the BBC homepage. Now where are the access keys (and I don't remember them)? There is a link "Accessibility help". Click on that - still nothing about access keys.

Just to let you guess how many people will end up using access keys on the BBC site. This is not intended to make laughs your idea, but to show what direction definitely not to go. Hiding information will for sure make it used less.

So what I see in your proposal of hiding the information from the links (let's call it progressive disclosure)":

  • Good:
    • Access keys no longer rely on the actual characters in the words, so potentially easy to create one global set of keys.
    • We can provide more information about access keys and the necessary key combinations.
    • Cleaner looking links without loosing functionality for power users.
  • Not so good:
    • Information is more hidden, so occasional users will find it hard to even find what they are not missing. They will simply not miss it.
    • Because of this they will find it harder to become intermediate users. TWiki lacks in more areas, for instance the small set of instructions in Edit do not make it easier to learn variables for instance.
    • The cleaner looking links are compensated in the form of the extra link to access key info.
  • Open questions:
    • Is a global set of keys actually good? I would say that 'E' is very easy to remember because it is the first letter of 'Edit'. But in Dutch it is 'Bewerken' and suddenly 'E' is not so logical. And using '1' for Edit, '2' for Attach, '3' for Cancel won't make it easier.

Instead of using a popup we could also think of using the title tag to show the extra information. For instance "Edit this topic text (E)". But it does look cryptic, and "Edit this topic text. Or press access key E" doesn't enlighten us either.

-- ArthurClemens - 19 Dec 2006

Found a very bad example of how irritating wrong visual feedback can be -- well, it's not that bad, cause the underlined letters are no shortcuts resp. access keys, they are for activating the menu functions via the keyboard while holding the 'Alt' key.

firefox_keys.png

The solution would be to take terms and access keys that work in all languages, e.g. for the bad example: change the position of the underlined letters within the german terms (e.g. Seiteninformationen and DOM Inspector). Even Microsoft is consistent in this on multiple languages, why not borrow their terminology?
BTW: Has anybody done terminology management via TWiki? wink

Anyway, our motto should be: if we provide the feature, we at least do it right, right? smile

-- FranzJosefSilli - 19 Dec 2006

Sorry, what is consistent in this example?

-- ArthurClemens - 19 Dec 2006

Just following up on this conversation with a thought as I use [ALT-S] to save a topic. I don't know what I would do without this access key, it's just become an engrained part of what twiki is to me.

The best idea I've seen so far is to let the user decide on his own access keys. That's what I'm prompted to do when I boot up my PuppyOS for TWikiOnMemoryStick, and I'm happy to do it. I tell the OS that I want the US keyboard map and it gives it to me, instead of japanese.

So the plugin to solve this problem would be the AccessKeysPlugin. It would provide a list of standard TWiki.AccessKeyMaps that the user could choose from in his or her UserPreferences. It would also give the user the ability to create his or her own TableWidgkit and define a new AccessKeyMap.

Before the creation of this plugin, the next best option would be to let the administrator choose the key map at the skin level. Thankfully, the KoalaSkin let's me do this, and I've happily done so after the creation of my new DashBoard. I had to choose [ALT-B] as the access key for my dashboard because [ALT-D] was already taken by show diffs, a compromise I was willing to take. But now that I've got [ALT-B] memorized it makes about as much sense as cutting with [CTL-X] and pasting with [CTL-V], it's got nothing to do with the language I speak. It's what works, I use it, and yes: it is very much worth the trouble smile

-- KeithHelfrich - 21 Dec 2006

Shall we just stick to the English AccessKeys and add something like (E) in languages where the letter is not present? On top of that we could just better document things on AccessKeys and KeyboardShortcut and at some point offer user customization using plugin or skin.

-- StephaneLenclud - 21 Dec 2006

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng firefox_keys.png r1 manage 2.5 K 2006-12-19 - 20:42 UnknownUser Firefox 2.0 (de) - menu "Extras" with access keys
Edit | Attach | Watch | Print version | History: r20 < r19 < r18 < r17 < r16 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r20 - 2006-12-21 - StephaneLenclud
 
  • 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-2015 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.