- From: Charles McCathieNevile <chaals@opera.com>
- Date: Sat, 22 Sep 2007 16:08:44 +0200
- To: "Maciej Stachowiak" <mjs@apple.com>
- Cc: "public-html@w3.org WG" <public-html@w3.org>
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. Details... The basis of my proposal 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, and there is already a shortage of available keys in many existing devices. 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. 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 - and we should assume that implementations may 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:09:15 UTC