Accessibility, Internationalization, and Keyboards (#2: Accelerators)

by Michael S. Kaplan, published on 2004/12/24 02:21 -05:00, original URI:

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:

That was very intresting. Thanks indeed! Waiting for the Alt-Gr explanation... :-)

# Centaur on 25 Dec 2004 11:19 PM:

Accelerators most certainly do suck.

In Russia, you have to have both an English and a Russian keyboard layout. And accelerators in localized programs work when the Russian layout is active and accelerators in non-localized programs work when the English layout is active. And in non-localized programs you have &File|Save &as, while in localized programs you have &Файл|Сохранить &как, which in terms of keys translates into Alt+A R. So there’s no pattern to memorize subconsciously, because you have to remember which program you’re in.

So there is a big camp of users who just set up an English version of Windows and curse when a third-party program decides that just because the system locale is set to Russian it should default its UI to Russian.

# Michael Kaplan on 26 Dec 2004 1:33 AM:

Oh, I agree that the system locale should not be used for the UI language -- thats what GetUserDefaultUILanguage is for!

# Philip Newton on 26 Dec 2004 9:14 AM:

I, too, am looking forward to the essay on the origin and meaning of the name "AltGr"!

# Norman Diamond on 26 Dec 2004 7:07 PM:

Alternate Graphics? European keyboards need enough shift states to type a bunch of alphabetics (and I think sometimes punctuation). European keyboards have room for both an Alt key and an AltGr key because they don't need to have the kind of keys that Japanese keyboards have near the space bar.

Japanese keyboards usually don't have right Alt or right Ctrl keys. (Notice the "usually". Keyboards for desktop systems have those keys, but laptop systems and laptop keyboards are more numerous.)

# Michael Kaplan on 28 Dec 2004 12:40 AM:

Ok, the AltGr post is up at :-)

# Centaur on 28 Dec 2004 7:46 AM:

> thats what GetUserDefaultUILanguage is for!

Exactly. Except it came up some seven years too late :(

> Windows NT/2000/XP: Included in Windows 2000 and later.
> Windows 95/98/Me: Included in Windows Me.

# Michael Kaplan on 28 Dec 2004 8:35 AM:

Well, sort of. For Win9x the system locale cannot be changed, and for all platforms the user locale is for something else.

So if you have applications that use these settings for the UI language *ever* then they are doing it wrong.

And this *will* be a topic for another day, a I have strong opinions on this. :-)

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

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?

go to newer or older post, or back to index or month or day