Accessibility, Internationalization, and Keyboards (#1: Shortcuts)

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

This post will be 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).

As it is the first post, there will likely be questions in people's minds that relate to items that will show up in future posts; I promise I will be flattered that I was able to inspire such issues before covering them!

This is a huge area. Talking about keyboards, MSKLC, accessibility, surrounding international issues.... the list of topics not being covered may have been shorter....

Anyway, lets start with shortcuts.

These little beasties are a crucial way for some to get at core functionality. While some people prefer to go to use Edit|Cut, Edit|Copy, and Edit|Paste from the menus, many others like by <CONTROL + X>, <CONTROL + C>, and <CONTROL + V> for the functionality all across Windows. This is so true that the developers who wants to change the functionality from Cut/Copy/Paste to eXchange/Contribute/Verify will find that they face an uphill battle, fighting spinal reflexes and muscle memory.

There are other common shortcuts such as <CONTROL + A> for "Select all", <CONTROL + Z > for "Undo" and <CONTROL + Y> for "Redo", or the other magical editing shortcuts like <CONTROL + I> for italics, <CONTROL + B> for bold, and <CONTROL + U> for underline. Users are dismayed when they do not work if it seems like they ought to (like in a text editor  -- I tend to define an "immature edfitor" as one that does not have these definitions!), and one of the best ways to upset users is to have that functionality and put it on some other shortcut. Or even worse to have no shortcut at all!

(There are other shortcuts that you can find out about by looking for the article entitled "Windows keyboard shortcuts overview" in Windows Help, but I am not referring to most of those, I am referring to application shortcuts that a developer might put in their application). But I highly recommend that other article since it has a lof useful shortcuts in it and is very useful to users.)

There is an even cooler page from the Accessibility folks entitled Keyboard Assistance that covers many of the applications that Microsoft ships beyond Windows. In fact there is only one part of that page which is not so great, which I will point out in a moment. I am not making up the importance of shortcuts and accessibility. Ignoring the fact that they host this site, they host articles like the one from Sara Ford1 enitled Testing for Accessibility which mentions shortcuts quite prominently in the accessibility testing that an application should do here. Incidentally, Sara's article rightfully does not try to separate shortcuts (the topic of this post) from accelerators (a topic coming soon). Why do I say rightfully? Because users do not usually distinguish and thus it is not entirely sensible for documentation to do so. Hell, I wouldn't separate them if I did not have to in order to describe the technical issues behind them that are the root of so many problems....

Anyway, these shortcuts are boon to people who have difficulty using the mouse and they open up worlds for people who want to get at that functionality. I love them even when I have no problems with the mouse because I do not have to break up keyboard usage (and I sometimes do have problems with the mouse, though for me the keyboard kind of sucks then too - but thats another story). This makes them a wonderful usabulity adjunct to people who have problems with using other means of common actions as long as they know about them, which is the reason that the commonly known ones are more likely to be used. I also must come back to Sara's articl, which has the coolest quote about accessibility in the world:

One final note about keyboard accessibility is that the more ways the user can perform a given task, the more accessible the functionality is.

This quote can even be extended beyond keybord accessibility, so I will be coming back to it in future posts since it was a guiding principle in the UI design of MSKLC.The more ways there are to perform a task, the more accessible the functionality is.

But as I mentioned, there is a spot where things fall down. Here it is....

Of course, they suck a little bit for languages that do not use the Latin script, where keys for X, C, V, A, Z, Y, I, B, U, and others are not present. I say "a little bit" since folks who buy a keyboard still have asccess to those shortcuts but they are under other keys. And who would instinctively know that <CONTROL + ฟ> on a keyboard with the Thai Kedamanee text layout printed on it would mean "Select All", that <CONTROL + न> on a keyboard with the Hindi Traditional layout printed on it would mean "Paste", or that <CONTROL + ਬ> on a keyboard with the Punabi layout printed on it would mean "Undo"? Some might actually make sense, but the odds of most of them meaning anything at all are unlikely.

One the other hand, things can also suck if you switch to another Latin script layout that does not match the letters on the keys on your actual keyboard. You may well be dismayed to see what looks on the hardware like <CONTROL + A> actually quit from your application rather than selecting all of the text when you switch to the French layout (since VK_A and VK_Q are switched). It may annoy you tremendously that the undo and redo functionality in what looks on the hardware like <CONTROL + Z> and <CONTROL + Y> seems to be swapped just because you switch to the German layout (where VK_Y and VK_Z are switched).

Speaking as a non-speaker of both the Latin and non-Latin category of languages, I am hard pressed to give an opinion on which is worse other than to say that I would think it was worse if it were my language. Dammit.

MSKLC actually comes in handy here -- you can load an existing keyboard layout and hover over the different keys to find out what is the key over each of these different letters. (Of course at that point we run into MSKLC usability issues, but thats a different issue, for another post!)

But why does that happen, exactly?

These items are not subject to localization since they are virtual key (VK_*) based and they can be subject to key repositioning when a keyboard layout repositions keys (for example the French layout switches the positions of "VK_A" and "VK_Q" which means that if I switch to the French keyboard on my US keyboard hardware I have to know that the key that has "A" printed on it is really going to mean QUIT if I hit it with the control key). Thankfully, outside of the Latin script languages there is very little moving around of the VK_* values.

This is a place where Chinese, Japanese, and Korean language keyboards do just as well (which is to say poorly). They keep the English positioning on the VK values even when a non-English keyboard layout is used (like in Japanese and Korean), which puts them with the rest of the non-Latin script languages. They regularly include the shortcut key in their user interface, on menu items and such, which is fairly cool. Of course this does not help if you do not know where the keys are, since they may not be printed accurately to the physical keyboard, but this makes them no worse off than every other language....

MSKLC does not offer direct customization here for where the virtual keys go; you can only indirectly change them by changing what scan codes go with what keys. This limitation has an interesting history and reason which borders on and approaches yet does not completely reach a justification -- see a future post for mone info!)

Note that beyond VK-repositioning there is no other consequence of letter assignment since localization does not affect the letter to be used (other than the fact that people may not be able to find them) and there is no dependence on anything outside of ASCII/VK stuff. Luckily, most other layouts do not move VKs around but a lot of Europe and elsewhere do so there is no 100% clean solution here.

So the place where shortcuts fall down is when the keyboard layout is switched so that it is different than the keys on the keyboard. Because then the discoverability of the shortcuts is significantly lower.

I just feel like every keyboard in another language should come with a huge mapping of the shortcuts, which is to say the VK_* assignments, to the key on the keyboard that represents it. Wouldn't that be a cool feature to have available when buy a keyboard? Or even better, any time you select a new keyboard layout, since where the biggest accessibility problem lies. This may not be practical but it seems like it would be handy! Well, that or the hypothetical keyboard whose key tops change letters when you change the layout2.

Addendum 23 Dec 2004 11:10am: The Japanese subsidiary has provided a good translation for some of these shortcuts here.

For developers, it is important to understand one more issue (assuming that your heads have not yet exploded). Thau is the fact that shortcuts are processed at the point of the WM_KEYDOWN message. This is very different from accelerators (which I will talk about another day) and is the main reason that there is no localization of the shortcuts -- they are processed before the virtual key is ever translated into a character. So while it may be useful to give documentation about how <CONTROL + ф> will make the text bold with the Bulgarian keyboard layout, it really is <CONTROL + B> that is doing the work. Windows never gets to the point where VK_B gets converted to U+0444 (CYRILLIC SMALL LETTER EF).

So, how to summarize this mess? I just looked over this post again after I was done writing it and realized it was a bit like the movie The Survivors3. There is no way to summarize it.

Except maybe to say that keyboard shortcuts are cool. Although they kinda suck sometimes, internationally....


1 - Sara's blog is an awesome resource that is on the short list of blogs I read, and not only because I screwed up accessibility to much on the mosdt visible piece of UI I have ever created. Its incredibly insightful, and she and I are fellow travelers in that we are both passionate about areas of which it is often tough to convince people of the importance.

2 - Although I am not aware of any commercially available keyboards that do this, it is a deisgn architecture that is wonderfully implemented on a project that Wei Wu, myself, and several TabletPC developers put to good use for the first update to the TabletPC soft keyboard, which has the job of emulating keyboard hardware. Changing the layout changes what shows up in soft keyboard, which is such a huge leap forward in the usability of everything except for shortcuts that it amazes me. It is of course not helpful for shortcuts since the universal documentation still talks about <CONTROL + X> for cut, etc. and the soft keyboard cannot change any of that.

3 - The Survivors (starring Robin Williams, Walter Matthau, and Jerry Reed). A fun movie. I remember an interview withJerry Reed where he was asked to summarize the movie and he said it was impossible to summarize -- the point of the movie kept changing every ten minutes.

This post brought to you by "" (U+ff73, a.k.a. HALFWIDTH KATAKANA LETTER U).

# Nektar on 23 Dec 2004 2:54 AM:

There are other more internationally friendly shortcuts for performing Cut, Copy and Paste. These are shift+del, ctrl+insert and shift+insert. Why don't you use other keys than letters for shortcuts. For example what are the function keys doing all these years? Nothing!

# Norman Diamond on 23 Dec 2004 5:03 PM:

> who would instinctively know that
> <CONTROL + ฟ> on a keyboard with the Thai
> Kedamanee text layout printed on it would
> mean "Select All",

Even in Japanese and English, I didn't know _instinctively_ that Ctrl-A would have that effect, but became accustomed to it in Microsoft systems because menus often showed the shortcut. If Thai menus show the Thai shortcut that you described here, then I would expect Thai users to become accustomed to it the same way.

By the way the Thai Kedmanee keyboard that I saw had both Thai and Italian characters printed on its keys. I don't know if all Thai keyboards do. And as far as I could tell, unlike Japanese users who ignore the kana printed on keyboards but type Italian characters and rely on the IME to produce kana (and then optionally proceed to converting to Kanji), Thai users really input Thai directly from the keyboard, switch to the keyboard's Italian characters when needed and switch back. I think they would likely pick up Ctrl-A as quickly as they would pick up the Thai shortcut that you described, if menus show the shortcuts.

> You may well be dismayed to see what looks
> on the hardware like <CONTROL + A> actually
> quit from your application rather than
> selecting all of the text when you switch to
> the French layout

I think you mean when continuing to use a US keyboard but setting an option to pretend that its layout is French. French users have a completely different issue. French users use a French keyboard with an option saying that its layout is French. Seeing your present statement in conjunction with some of our discussions in other threads, I wonder if you didn't notice the difference, I wonder if you thought that a solution for one hardware situation would work for the other hardware situation. It doesn't.

> This is a place where Chinese, Japanese, and
> Korean language keyboards [...]
> They keep the English positioning [...]

I really don't like deviating into political issues, and if you dislike it just as much then you will avoid words like "keep" there. I had to bite my tongue off to keep from mirroring your statement.

Now, in positioning Italian alphabetic characters and current European digits, Chinese and Japanese and English keyboards (and some others) have the same layout, and I genuinely take your word for it regarding Korean keyboards. For punctuation marks they do not. The US keyboard does not even share the English layout when it comes to " and @. Get one from England and you'll see.

> Of course this does not help if you do not
> know where the keys are, since they may not
> be printed accurately to the physical
> keyboard,

When a keyboard is manufactured in conformance with a national standard, and common practice is that 99% of the time software accepts input matching what is on the keyboard (though there are a few exceptions where common practice is that software accepts input from one key as being different and does not accept input from some others, because those keys are printed with characters that do not exist in the national character set[*]), it is incumbent on you to regard the keyboard as being printed accurately (with the exceptions just noted). You have no right to designate the keyboard as not being printed accurately and pretend that software is displaying accurate instructions. If you can't fix the software, then simply report that the software is wrong. The blame does not shift to hardware.

[* Why does a national standard call for making keyboards with a few characters that don't exist in a national standard character set? Well, why would two sections of a department of a government ministry ever talk to each other, and why should this be anything special? Not that anyone outside of government likes it, of course.]

# Michael Kaplan on 23 Dec 2004 7:47 PM:

Actually, the issue can happen with any keyboards layouts switching to any other, its not just US switching to another language. It can easily happen for a French user switching to German or English or Swedish.

I have a huge stack of other language keyboards in my office that I use to look at MSKLC issues, and have verified that this is the case for all language hardware switching to another language layout....

But keyboards have no special rules that make the text come out -- there is software that maps the scan codes the keyboard hardware into what you see on the screen. It willoften be the case that what the keyboard prints on its keys does not and cannot match what it types, but generally speaking the keyboards that MS makes try not to do that. :-)

There will be more on this another day....

# Michael Kaplan on 23 Dec 2004 8:27 PM:


I do not disagree with you, but the documentation folks have not embraced these ones as opposed to the others. :-(

# Mike Dimmick on 24 Dec 2004 6:42 AM:

Unfortunately what you call shortcuts the Win32 API calls accelerators. Windows doesn't translate them: the application does, typically using TranslateAccelerator. If TranslateAccelerator returns non-zero, the message pump is typically coded not to call TranslateMessage or DispatchMessage, so the keypress 'falls out' of the loop.

TranslateMessage is responsible for turning WM_KEYDOWN into WM_CHAR. I once wrote a sneaky piece of code - for adapting DOS programs - which calls TranslateMessage then pulls the WM_CHAR message out of the queue so that both keys that produce characters and keys that don't could be incorporated in a virtual keyboard buffer.

Your accelerators are handled by IsDialogMessage, if running a non-modal dialog (most frameworks, such as MFC and Windows Forms, fake modal dialogs by disabling the dialog's parent). I believe the Win32 modal dialogs - DialogBox - call IsDialogMessage from the internal message pump. Again, it's up to the message pump author to not translate or dispatch the message if IsDialogMessage returns non-zero.

# Serge Baltic on 4 Jan 2005 10:58 AM:

Isn't it a big mistake that the latin keyboards differ in alphabetical keys layout? This causes much headache when travelling. And provided that most of the computer users learn the keyboard layout from a scratch, without any typewriter experience, a unified layout would not have caused any trouble …

# Michael Kaplan on 4 Jan 2005 11:01 AM:


Well, from the point of view of a user who is used to a particular layout, sure. But telling people who have been typing their language all their lives that they have to do it differently to be more compatible with English would probably be a bigger mistake....

referenced by

2012/10/25 The promise and limitations of Dvorak...

2008/06/19 Accelerator vs. Shortcut, revisited

2006/03/28 Getting all you can out of a keyboard layout, Part #5

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/24 Accessibility, Internationalization, and Keyboards (#2: Accelerators)

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