by Michael S. Kaplan, published on 2004/12/24 02:21 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2004/12/24/331661.aspx
This post is one of a series that I will be putting up over the next few weeks about international and non-international issues surrounding keyboards, MSKLC, and accessibility. Through them I will deal with issues important to developers in their application, issues important to keyboard authors in their works, and issues important in the use of MSKLC (and MSKLC's own accessibility triumphs and failures).
The first article is very related to this one and is about shortcuts. In this article I promise that I will do plenty of riffing on the differences between the two.
If, you read the first post (link above) then you know about how weird shortcuts can get in international scenarios.
But think for the moment about how they use the basic keystrokes and do not care what is under them in the way of characters.
Accelerators, on the other hand, use the menu architecture. In fact the virtual key name for the ALT key is VK_MENU , which says a lot about the original intent of these keys.
Note: Most European keyboard layouts hijack the ALT key on the right side of the keyboard to get a new shift state. It is usually labeled ALTGR for reasons that I will explain another day. :-)
A good example of Accelerators is <Left Alt>+<f> to open up the File menu or <Left Alt>+<d> to select the "Destroy" button on the dialog. These accelerators do not use the keystrokes like shortcuts do, they use the actual characters that show up in a WM_CHAR message if the application passes the WM_KEYDOWN message to DefWindowProc.
The upshot of this differences is that they are 100% subject to both localization of the menu items to control the choices and also the keyboard layout choice which may or may not contain the letters in question. This means that anytime the user's keyboard layout does not contain the characters used in the shortcuts
Now other controls can have accelerators on them, and they are often considered wonderful accessibility helpers for that reason. Anyone who has ever tried to look at a web page and had to scroll through dozens or even hunderds of controls and URLs knows that tabbing between controls is not a very usable option.
Note that any time the keyboard layout language does not match the product's localization these items will not work. This includes CJK (Chinese/Japanese/Korean) is the one place where the specific language is used (for what its worth); because you cannot type Kanji in single keystroke, the localization effort usually includes ASCII letters for accelerators. Every other language can have problems here, and even the CJK languages will have problems if you switch to a keyboard layout that does not have the ASCII letters in it. CJK and English (note that you can verify this by opening notepad on an English Windows and switching to a Hindi (or any other language) keyboard and then try to access accelerators -- they will not work.
On the whole, this means that accelerators almost always have potential to suck from the standpoint of accessibility. While shortcuts only suck until people learn where they are in other languages, the accelerators will always be broken when you switch languages and should thus never be used to meet accessibility requirements since they can easily be made unavailable.
Now shortcuts and accelerators do both have some things in common -- for example, they both cannot have Han on them, and they also cannot really have dead keys or ligatures (in the keyboard sense -- two or more UTF-16 code points -- not in the typographical sense).
Yesterday I mentioned how all of the great resources that list out shortcuts tend to lump shortucts and accelerators together. This is okay a lot of the time since in many cases the default keyboard matches the localized language of the application. But this is easily broken any time you switch keyboards to type in another language!
Note that this also points to a suggestion for keyboards that you build yourself using MSKLC -- you might want to consider whether there is a sensible place to put the letters of the language into which most localized products are used so that one can use the common accelerators used in the application. This may not be feasible, but if it is then users who prefer to use keybaord accessibility methods will probably be very thankful.
This post brought to you by "࿇" (U+0fc7, a.k.a. TIBETAN SYMBOL RDO RJE RGYA GRAM)
# Andreas Wölfer on 24 Dec 2004 1:08 AM:
# Centaur on 25 Dec 2004 11:19 PM:
# Michael Kaplan on 26 Dec 2004 1:33 AM:
# Philip Newton on 26 Dec 2004 9:14 AM:
# Norman Diamond on 26 Dec 2004 7:07 PM:
# Michael Kaplan on 28 Dec 2004 12:40 AM:
# Centaur on 28 Dec 2004 7:46 AM:
# Michael Kaplan on 28 Dec 2004 8:35 AM:
referenced by
2012/10/25 The promise and limitations of Dvorak...
2008/06/19 Accelerator vs. Shortcut, revisited
2005/03/24 Accessibility, Internationalization, and Keyboards (#4 Creating good keyboards, part A)
2005/02/09 New info about old usability tests
2005/02/02 Handling shortcuts and accelerators in a real world situation
2005/01/03 Accessibility, Internationalization, and Keyboards (#3: MSKLC's UI)
2004/12/28 "To start press the ALTGR key." Hmm... where's the ALTGR key?