Re: Proposal for Keyboard Shortcuts for HTML5

Hi Charles,

On Sep 21, 2007, at 3:44 AM, Charles McCathieNevile wrote:

> Summary: I think the proposal makes sense in many aspects. I support  
> the substance as "we need to fix keyboard shortcuts" and some of the  
> details proposed (and have even made some of them to this group  
> before [1][2]).
>
> But I don't support introducing a new attribute. I think this  
> proposal needlessly reinvents wheels rather than paving cowpaths,  
> breaks backward compatibility, fails to resolve an existing problem  
> with accesskeys (that IMHO is an implementation bug that has nothing  
> to do with the markup spec and everything to do with poor  
> implementation advice that was given in the HTML 4 spec), and makes  
> assumptions about how accesskey can be implemented that are much  
> more limited than even existing implementations.
>
> The good stuff in this proposal can be applied directly to the  
> accesskey attribute as it exists, leading to better, backwards- 
> compatible implementations, while minimising the need to change all  
> the guidance given and tools developed so far and obviating the need  
> for a new attribute.

As stated in my proposal, I don't think the same benefits can be  
achieved using the accesskey attribute while maintaining  
compatibility. Just to give an example, let's say I'm writing a web- 
based mail client with a toolbar offering some common commands. The  
toolbar button to compose a new message just says [Compose], because  
in context and with the icon above that seems clear. But I'd like to  
have the label in a menu listing the shortcut keys to say "Compose New  
Message", since it is out of context. I'd like it to use some shortcut  
based on N in clients with a full keyboard, and something based on 1  
in clients with only a numeric keypad available. Under my proposal,  
you'd do it like this:

<command id="compose" shortcutkey="n 1" label="Compose New Message"  
onclick="compose()">

<input type="button" value="Compose" onclick="compose()">
(Or <input type="button" value="Compose" command="compose"> if the  
command attribute ends up working like I think it does.)

How do you suggest this could be done with accesskey? Note that using  
space-separated values in accesskey will fail in current UAs, thus  
removing any backward-compatibility benefits.


> Details below...
>
> On Thu, 20 Sep 2007 13:03:03 +0200, Maciej Stachowiak  
> <mjs@apple.com> wrote:
>
>> Keyboard shortcuts are useful for a number of reasons:
> [some reasons]
>> HTML 4.01 has a feature for keyboard shortcuts, the accesskey=""  
>> attribute. But it has many problems:
>>
>> - It is tied to a specific control in the page. But in native  
>> applications, many keyboard shortcuts do not have a direct one-to- 
>> one correspondence with a specific control element. For example,  
>> you may want a shortcut to focus an element that is also capable of  
>> activating, or vice versa, but accesskey can't let you choose which  
>> to do. Or you may want increment and decrement commands where the  
>> in-page UI is a slider control.
>
> This is indeed a problem of accesskey.

Do you have a proposed solution, based on accesskey?

>> - Keyboard shortcuts are not discoverable. It's not obvious looking  
>> at a web application whether it even has keyboard shortcuts, let  
>> alone what they are.
>>
>> - There are barriers to the UA making keyboard shortcuts  
>> discoverable.
>
> This is an implementation issue. In Opera, if you activate accesskey  
> mode (shift-esc is our current default, which I agree is non- 
> intuitive. I remap it to one of the find-as-you-type shortcuts) then  
> you see all the things that have accesskey. It would be helpful if  
> there were an indicator that there is something there, but that's  
> not a big deal.

I don't see how this works if the thing that has the accesskey is not  
visible in the page.

Also, hitting an obscure key combination to enter a special mode is  
far inferior usability-wise to a menu that shows the available  
commands with their keyboard shortcuts. A keyboard shortcut mode would  
not be acceptable by Apple's standards of usability.

> In mobile implementations that I have used they generally do insert  
> content - but these have been low-end mobile devices that don't do  
> much presentation anyway. Showing, in high-end devices, that there  
> is something there if you activate accesskey mode is not asking for  
> a huge amount of real estate.

This again assumes that there is such a thing as "accesskey mode".  
Hidden modes will greatly reduce the benefit to end users and the  
desire of authors to use the feature. Consider that every native win32  
app, every native Mac app, and every native GNOME/KDE app has keyboard  
shorcuts, but by your survey only 2% of web pages attempt to do so,  
and many popular web apps appear not to have any.

As I said in part of my original email that you snipped: "Having a  
visual indicator that appears when the user depresses the appropriate  
secret modifier key is only discoverable if the user knows the secret  
modifier, which is unlikely to be the case." If you want, we can try  
to put the shift-esc system vs. the shortcut menu to the test in a  
user study, but it seems so obvious to me which is better that it  
hardly seems worth the effort.

>> - There are barriers to the web app making keyboard shortcuts  
>> discoverable. The web app does not know what modifier keys the UA  
>> will add, if any, so it cannot display the true shortcut in the  
>> page or in help materials.
>
> Indeed. This is not a barrier to doing it though, it is a very good  
> reason why the web app typically should not do it. Poor  
> implementation until now has meant that authors have tried to tell  
> users what the key is since otherwise there is literally no way of  
> knowing, in some popular browsers, that your common shortcuts have  
> been "hijacked".

I pointed this out mainly because I don't think either the UA or the  
web app can do a good job.

>> - The set of keys available for shortcuts is not the same across  
>> different devices, operating systems and browsers, but the syntax  
>> for accesskey requires choosing one.
>
> Indeed. But nothing in the syntax and markup as used today requires  
> that the browser assign that key. Indeed, several middle-ware or  
> extension-based implementations explicitly provide for re-mapping to  
> something more useful for a given platform.

True, but the syntax and markup as used today only allow the content  
author to make one suggestion to the UA, if they have several good  
options but only desire a single keybinding to be made. I don't see  
how this is solvable without changing the syntax, and if we make an  
incompatible syntax change, why not add a new attribute for the new  
syntax, while still leaving accesskey available for backwards  
compatibility?

>> - The UA may wish to present a list of available keyboard shortcuts  
>> to the user in some sort of list, but there may not be a good label  
>> available. All the UA can use is the label of the control, but a  
>> label that's good in the context of the page may not be very good  
>> in an out-of-context list.
>
> There are several indicators that can be used. The content of a  
> control (e.g. the text of a link, or an image used in a link) and  
> the value of the title attribute are the most obvious. For form  
> controls, the value of a <label> element.

None of these examples solve the problem that the in-context label is  
not always good to use as an out-of-context label.

> The example Maciej provided is a sadly common one where content is  
> not very clear about what it does - a similar example is several  
> controls labelled "click here". (There's a reason why WAI has been  
> asking people not to do that for years - and a number of people got  
> the message, though not all).

Unfortunately studies seem to show that links with highly actionable  
labels like "go" or "click here" are more likely to be clicked. But to  
make the text less generic:

<form ...><input type="text" placeholder="Amazon"><input type="submit"  
value="Search"></form>
<form ...><input type="text" placeholder="Web"><input type="submit"  
value="Search"></form>

"Search" makes sense as a button label in context, but in a list you'd  
want to see "Search Amazon" and "Search the Web". You shouldn't have  
to change in-page UI that works fine just to get better labels for the  
keyboard shortcuts.

> For a desktop client it isn't that complicated to extract what the  
> control activates, check whether anything else activates that  
> control and whether anything that activates a different control has  
> the same default label, and then use a heuristic to select the  
> "best" label available. This could be written into an extension in  
> userJS or similar. But you probably wouldn't want to run it on your  
> phone - there it would be better built into a proxy...

I don't understand how this would work. How can the UA choose which of  
two natural language labels is "best"? If the action on the control is  
a script, how would it determine what else (if anything) has the same  
action?

>> I have a proposal that I believe could provide a better solution:
>>
>> HTML5 introduces a new <command> element which allows commands to  
>> be defined in an abstract way that can be shared by multiple UI  
>> elements.
>
> This seems similar to the access element in XHTML 2. Maybe it would  
> be better to give it the same name, and just improve the definition.

Sorry if this was unclear. <command> is already in the draft, it's not  
a new proposal from me. It is a representation of a command action  
which can optionally be controlled by one or more interface elements  
that activate the command.

> Or is there some reason for being different that I have missed?

I understand pretty well what a command is, and what it means to  
define a command. What's an "access"? Does it make more sense for a  
menu have a list of commands, or a list of accesses? I would be  
against renaming "command" to "access" because I think having a  
reasonable name is more valuable than XHTML2 compatibility.

>> I propose that the command element be given a new attribute,  
>> shortcutkey.
>
> Why not call the attribute "key" (for comaptibility with XHTML2)

I don't think any weight should be given to compatibility with XHTML2,  
but others have suggested just "key" or "shortcut" for brevity.

> or "accesskey" for compatibility with the Web?

Since the legal values, expected behavior, and set of elements where  
it would be allowed are all different, I don't think reusing the name  
would provide compatibility with the web.

>> The value is either empty or a space-separated list of characters.  
>> If the value is empty, the UA can assign any shortcut key  
>> combination it wants. If a list is provided, the UA should use that  
>> as a list of suggestions from most preferred to least preferred for  
>> a key that should be assigned, [...]
>> If none of the suggestions is available, the UA should assign a  
>> keyboard shortcut as if the value were empty.
>
> This is close to my accesskey proposal [1] but has an advantage in  
> clarifying that you can have more than one character. A further  
> clarifications that should be added:
>
> User agents should assign a unique control (e.g. key value) to each  
> unique action. (Which answers the question "what happens if you have  
> two controls with the same accesskey?" that is currently unspecified  
> in HTML).

Agreed. This was my intent, if the requested keys have already been  
assigned the UA should choose a unique value if any are available.

>> in possible combination with one or modifier keys.
>
> I strongly suggest implementations do not rely on using a modifier  
> key as an accesskey mechanism. In most uesr agents today users  
> expect a particular behaviour from modifier-plus-key for a number of  
> combinations (as noted in the original mail), and overriding those  
> makes for unpredictable behaviour. Indeed, the single biggest real  
> problem with accesskey as implemented in Netscape, Firefox prior to  
> version 2 and IE is that they override existing keys that users rely  
> on.

I don't think overriding should be allowed. Safari at present does not  
allow override of key combinations that have built-in bindings.  
However, there's more than one modifier combination available per key.  
For example, Cmd-N is taken in Safari on Mac but not Cmd-Shift-N. And  
using one or more modifier keys  is the standard way for native apps  
to expose keyboard shortcuts. I don't think web app keyboard shortcuts  
would work in a completely different way.

>> For traditional desktop UAs that they add a menu to their menu bar  
>> or a toolbar, with a name like "Commands", "Shortcuts", "Page  
>> Shortcuts" or similar, which includes the commands with their  
>> labels and the keyboard shortcuts assigned by the UA. Check or  
>> radio commands could create check or radio menu items.
>
> This is roughly how Opera implemented accesskey.

Can you suggest a web page where I can see it in action? I tried  
visiting the following page, and could not find any reference to the  
access keys in visible UI: <http://www.cs.tut.fi/~jkorpela/forms/accesskey.html#ex 
 >. If the page didn't mention them, is there any way I could find out  
this page even had keyboard shortcuts without hitting Shift-ESC? Is  
there any place in Opera's UI, other than the help file, that I could  
even find out about the shift-esc shortcut? I'm pretty sure I would  
never have found out about it if you hadn't told me.

>> For mobile devices with only a numeric keypad available, they could  
>> assign 0-9, * and # to shortcuts in some order and optionally  
>> display a list of shortcuts with labels below the bottom of the page.
>
> This is what existing mobile browsers generally do (except that most  
> of them rely on those characters being specified as the accesskey  
> already). In fact it makes more sense in many cases to provide an  
> accesskey mode, the same as I suggest for desktop, since modern  
> phone browsers use the raw keypad for a number of handy functions  
> like moving the cursor, going to the top of the page, etc, to avoid  
> requiring too much menu navigation for common functions.

Once you have to press two keys, it's not nearly as much of a  
shortcut. Many phones, even basic models, have "direction" keys  
separate from the numeric keypad as well as soft keys. But I think  
this should be up to the individual UA. On the desktop using a mode is  
just bad UI, on a phone it may make sense in some cases.

>> For devices with only touchscreen input and a virtual keyboard, it  
>> may make sense to have no interface at all for keyboard shortcuts  
>> since using a virtual keyboard is unlikely to be faster or easier  
>> than interacting with the page directly.
>
> Alternatively, it may make sense to do what Opera does on desktop:  
> When you activate accesskey mode (which would be with a gesture) you  
> get the menu that just contains the things that have accesskeys  
> assigned. On a large page which would have required scrolling around  
> to find the bit you want, then hitting the control, this may be  
> quicker for common actions.

I am dubious that a UI with hard-to-use in-page actions can be  
improved with a hidden command mode.


I forgot to mention one other major problem with accesskey. HTML4 says  
that the effect of activating an accesskey should be to focus the  
element. But this is very rarely the desired action for a keyboard  
shorcut. Almost always you want the shortcut to activate something or  
do some script action. Although the spec seems confused on this point,  
since it gives some examples of focus that sound more like activation.


>> Notes:
>>
>> - This is much closer than accesskey="" to the way keyboard  
>> shortcuts work in native desktop applications, a proven and  
>> effective model.
>
> In markup terms it is introducing a compulsory indirection.  
> accesskey in HTML 4 didn't have that idea, but if you have a command  
> element to provide the indirection as desired there is no reason I  
> can see not to simply extend the applicability of accesskey to that  
> element.

This only makes sense if you think of keyboard shortcuts as being a  
way to focus or activate an existing in-page element. But that's not  
at all what keyboard shortcuts are in native application UI toolkits,  
where keyboard shortcuts are much more successful. That being said,  
there's no problem with allowing shortcutkey to also be present on  
command-defining visible elements like <a> and <input>.

> As far as I can see, the biggest value of the command element is  
> that it solves the first problem you mentioned - that you can then  
> assign a command to increasing the value on a slider, rather than  
> just having one default action for a slider.

There's many other examples like this, where the desired shortcut is  
to a command that doesn't directly correspond to a visible in-page  
element.

> It is also known ("proven" by a significant preponderance of  
> evidence) that changing established shortcuts is not helpful to  
> users. So relying on modifier keys in a situation like the diversity  
> of the Web, where the combinations are likely to conflict with other  
> functions, is generally not helpful implementation advice.

Relegating keyboard shortcuts to a hidden mode will indeed solve this  
problem, by ensuring that the vast majority of users never use them.

>> - The proposed model provides mode device-independence and  
>> discoverability than accesskey does, either as implemented today or  
>> in the best possible case in my opinion.
>
> I think you have seriously underestimated how a decent  
> implementation of accesskey would behave. Your proposal has a lot in  
> common with my proposed suggestions [2], but there are further  
> possibilities (some repeated in this mail) that could enhance the  
> usefulness of a keyboard shortcut mechanism. As a design goal, my  
> proposal maintained compatibility with the existing Web, and I  
> deliberately avoided introducing anything new. (I assume that  
> accesskey should "obviously" be applied to any element like command/ 
> xhtml2:access - but maybe I should be more explicit about that).

I don't see how it's possible to solve many of the problems my  
proposal solves without breaking compatibility.

>> - Assistive technologies generally know how to scan and operate  
>> application menu bars, so on desktop systems the commands would  
>> likely automatically be exposed to AT as well.
>
> yes.
>
>> - The name of the new attribute is deliberately different than  
>> "accesskey", since the semantics and allowed values are different.  
>> This makes it possible in theory for a page to use both accesskey  
>> and shortcutkey on the same element, if we end up allowing them on  
>> the same elements; they could have some level of keyboard access in  
>> older UAs but get the better new model in HTML5 UAs. I also think  
>> "shortcut key" is a better name, since keyboard shortcuts exist for  
>> all users, not just for accessibility purposes.
>
> Except as used by the "accessibility" community, accessibility on  
> the web is generally understood to cover issues that relate to  
> whether users can get to something or not. The specificity of  
> covering people with disabilities isn't part of english anyway.  
> (Change the language and the whole notion vanishes anyway).

That's just an aside, the main point is that by letting you use both  
you can get best behavior in HTML5 UAs but still do something in old  
UAs. That being said, the terminology in native UI toolkits is usually  
something like "shortcut" or "accelerator".

> If you maintained the accesskey name, and instead changed the stupid  
> implementation advice that is in the HTML 4 spec, along the lines I  
> proposed a few months ago [1] then you would in fact have the  
> semantics you are looking for, plus compatibility with existing  
> markup (and with the horrible implementations in some current  
> browsers).

I don't see how your proposal solves the labelling problem, the  
ability to suggest multiple keybindings, or the desire to have  
commands that are not tied to visible in-page elements. I also don't  
see how it is mutually exclusive with mine, necessarily.

> FWIW We have been doing some research into accesskey usage at Opera.  
> I hope that we will be able to publish enough information to make  
> this reproducible by anyone, but I can't promise anything yet. On a  
> survey of about a million pages, accesskey is used in about 1% of  
> them and it is used "right" according to the HTML 4 spec  
> requirements, that is as a single character, a bit more than 99%  
> (less than 99.5%) of the time. The most common accesskey is "s" and  
> the keys listed by the UK government guidelines for their own  
> websites (which have been taken up in other countries and in other  
> languages - other than "s" they use digits which is nice for phones)  
> seem to account for the majority of all keys assigned.

S conflicts with a common built-in binding and digits make for poor  
shortcuts in desktop apps, so this seems like evidence that current  
accesskey values are poorly chosen for use in existing browsers. So I  
don't think we lose much by making a clean break.

Regards,
Maciej

Received on Saturday, 22 September 2007 01:05:20 UTC