(Read this one) Mice, Majuscule and Modifiers Re: Keyboard Shortcuts

(please ignore earlier version - hit sent too soon :( )

Hi Maciej, Sander and all,

I assume people are familiar with the proposal from Maciej [1] to use a  
shortcutkey attribute (or something else not called accesskey) and my  
proposal [2] that we make accesskey behave more like Maciej suggests for  
his proposed new attribute, so I haven't directly quoted the increasingly  
long mails here - this mail is long enough.

The two things I want to discuss in this mail are Sander's questioning why  
Opera's acceskey menu (the thing formerly known as accesskey mode :) )  
isn't mouse-operable and Maciej's reply that a mouse-operable keyboard  
shortcut mechanism misses the point, and my assertion that relying on a  
modifier key model like shift-alt-[accesskey] isn't all that good an idea.  
I claim that these two points are actually closely related, and that it  
does make sense to make accesskey (or key, or  
shortcutKeyToAccelerateUserInteraction, or whatever you end up calling it)  
a mechanism which is mouse-operable, and does not recommend using modifier  
keys. (Most of this has been discussed before, often by my good mate John  
Foliot and I, in all kinds of fora. This mail attempts to distill the  
years of testing and discussion into a readable package)

The basis of my proposal for accesskey in HTML 5 [2] was a quick way to  
access the important controls in a web page or web application. For most  
desktop users and most phone users this implies keyboard shortcuts. But  
devices where this is not helpful (i.e. with no keyboard to speak of) are  
becoming increasingly common. The iPhone is an extreme example, with only  
one actual button, but touch screens and gesture-based interfaces have  
been around for ages - Opera's mouse gestures, various handwriting  
mechanisms, are the intellectual heirs of systems first developed a decade  
or two ago. There is also a shortage of available keys in many existing  
devices - especially those that cater particularly to keyboard users.

The purpose of a quick access method is, fundamentally, to allow users to  
work more efficiently - spending less time and less effort to activate  
some control. Having a gesture available to zoom is generally more  
efficient than having to go through two or three menus. For some people in  
some situations, a mouse gesture is the most effective way to go back,  
since they have the mouse in their hand already. For others, a keyboard  
shortcut is faster than a gesture since they have their hands on the  
keyboard. For others, the on-screen button is more efficient since they  
don't remember the other methods of activation.

Clearly, for a web application that fits onto a small screen with a small  
number of controls that are all visible and clearly seperated, there is  
not much need for a shortcut mechanism. But while sticking to this might  
be a good UI design principle, it is not a law (and certainly not an  
enforceable law).

Fitting onto a screen depends not just on the screen but also on the user.  
People use zoom at various levels, but the most I have come across in the  
wild is a full-size laptop screen being used with a line-height of 80% -  
that's 80% of the screen. Short words would fit all at once, long ones  
would not. Moving around such a screen is difficult - you have little in  
the way of navigation waypoints and rely on a very rigid layout - far more  
rigid than you find on the Web. (This particular user could not augment  
the context with voice output because he was completely deaf).

But there are also larger web pages, complicated forms, and so on. Being  
able to use the various controls scattered around them should not be  
restricted to the keyboard - on my partner's Wii I have no more keyboard  
than on an iPhone. And when I watch youTube videos, I zoom the video to  
take the full screen (it's more efficient than going to youTube's  
fullscreen mode, then going back in case I want to check the menu of  
related things or search or follow an ad or whatever). Navigation is not  
such a pain (youTube is relatively compact and the Wii provides good  
navigation), but it starts to raise the issue. When I read the newspaper,  
whether with the Wii or the iPhone, this becomes a real issue -  
theage.com.au (my preferred newspaper) like most online newspapers has a  
lot of links to different stuff on a given page, and getting back to them  
and using them is not so efficient.

Being able to call up a menu that gave me just the things that were known  
to be valuable (in my case it is actually the links to National, World,  
Cricket, and Rugby news, and the "Opinion" articles). The obvious way to  
do it on my desktop is an accesskey - and a userJS to add these as a  
per-site preference is even in my limited javascript capacity. It would be  
even better, of course, if I could add the userJS somehow to the page even  
when I was not on my desktop (and it turns out that doing this sort of  
thing through a proxy is a very old method already). But then I have the  
problem that neither iPhone nor Wii has an actual keyboard.

My preferred solution (and there are multiple possibilities) is that a  
gesture bring up the menu that Opera activates with shift-esc by default,  
and that I can then navigate that as an onscreen menu. Since it has a very  
rigid format, it also meets the needs of my example user above.

Finally, and importantly, it solves another problem most recently  
demonstrated by Firefox' improvement in their accesskey implementation. To  
resolve the hijacked UI issue, they moved to shift-alt as the modifier.  
This meant (oversimplified) that the characters received were shifted, so  
"s" becomes "S". And "1" becomes "!" - and the bug was that you couldn't  
recognise a "1" as an accesskey. (We have had a similar problem in the  
past actually, for different reasons).

In one of our surveys of accesskey, the most common one, found in almost  
1% of all pages sampled is "s" (despite the fact that, as many people have  
noted, this normally has an existing role with the "common" system  
modifier). The second most common is "1", found in about 0.7% of pages.  
All the digits are in the top 13 - the other letters there are "c" and  
"p". And the 18th most common, in about 0.15% of pages (i.e. 1/7 as common  
as "s") was "S". 7 of the top 40 values appear in both upper and lower  
case - in other words, about 1/3 of the letters are used in both cases.

I haven't done the inspections to determine whether you find "s" and "S"  
on the same page, or whether you could get away with case-normalising all  
accesskeys in current content. But talking to the people who worked on IE  
and Netscape/Mozilla years ago, they said that it was common enough that  
you have repeated use of the same value in a page that they had to account  
for that (I haven't checked for that either, and it could be a source of  
minor inaccuracy in my figures. In a survey of a million pages there are  
other sources of inaccuracy, but I believe the qualitative results are  
still useful).

But I would suggest that it is difficult to disambiguate cases. Likewise,  
it is difficult to activate letters that are not on your keyboard. While  
most people on this list seem to have little difficulty with latin  
characters, that is not necesarily true of most people. And I am not sure  
how most people would activate "ö" - which appears in our survey - or the  
extended range of characters I would expect to appear in a broader survey  
or if we improve the shortcut mechanism.

There are, of course, various ways of handling this issue. But it seems to  
me that one important strategy is in fact to allow an accesskey menu to be  
navigated - with arrow keys or directly by using the assigned accelerator,  
of course. But for many users, what will make them efficient is to call up  
the menu and be able to use a pointer-based navigation mechanism to  
navigate things they can see.

For one small group of users (those who can't see anything) being able to  
navigate the menu is important. Being blind doesn't automatically give you  
a good memory (or better sense of smell or hearing or income or anything  
else), it just requires you to use it more. Using a screen reader means  
you need to remember an additional set of controls to everyone else  
already - and they are almost always keyboard based since blind people  
don't generally get a lot of value from a mouse. Adding to that a list of  
accelerator keys for a page is really pushing the boundaries of optimism -  
but adding a single mechanism to get the list, and being able to navigate  
the list, is much more tractable.

So while applying modifier keys to an accelerator is one implementation  
strategy that has some value for some users (and is clear to some  
authors), I believe it has serious drawbacks for many users and platforms,  
and that we should not assume that it is the sensible default  
implementation even for keyboard-based platforms, and we should assume  
that some implementations will not actually use a keyboard at all.

[1] http://www.w3.org/mid/B2750F31-8ACF-4B46-8D02-44371AEE4C9F@apple.com
[2] http://lists.w3.org/Archives/Public/public-html/2007Jul/0185.html (and  
http://lists.w3.org/Archives/Public/public-html/2007Jul/0213.html  
discusses implementation strategies).

Cheers

Chaals

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo español  -  je parle français  -  jeg lærer norsk
chaals@opera.com   http://snapshot.opera.com - Kestrel (9.5α1)

Received on Saturday, 22 September 2007 14:12:34 UTC