Re: Proposal for Keyboard Shortcuts for HTML5

On Sat, 22 Sep 2007 03:05:05 +0200, Maciej Stachowiak <mjs@apple.com>  
wrote:

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

> 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.

Indeed, if you use accesskey="N 1" you have the same result as if you use  
shortcutkey="N 1" - only new browsers designed to pick it up will work.  
(Given the anti-user behaviour of some current browsers on accesskey, that  
might not be an entirely bad thing actually...)

But for the rest

<input type="button" value="compose" accesskey="N 1" title="Compose New  
Message">

would do it.

(Adding role="new:composeMail" where there is some way to discover what  
that is would be even more helpful. Since webmail is extremely common and  
important to many people it is the sort of role extension that might get  
native UI support reasonably quickly, if it got usage on major webmail  
systems.)

>> 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?

No, nor does it make sense to solve it with accesskey. You need something  
that can deal with more than one default activation method - which brings  
you back to the command/access elements that identify the function you are  
trying to use and give a hook into it.

>>> - 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.

You put a title (or label) on it, and use that. As in your example above,  
and the access element.

> 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.

Maybe I should describe Opera's accesskey implementation as a menu then  
(this is what the developer calls it). I am used to assistive technology  
(and to vi) where there are a lot of commands, so different command modes  
are considered a bonus.

Certainly one of the benefits of Opera's implementation over most others  
is that you get a visible menu listing the things with accesskeys. That  
said, there are improvements we still need to make.

>> 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".

Which may well be (should be, in most implementations) a menu, not some  
hidden mode that is really only available to power users.

> 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.

Given that nearly all browsers provide no way at all to discover that  
there are accesskeys (even when they implement them in a way that lets  
them hijack the standard UI) I think the 2% figure is surprisingly high.

Many popular pages have also, in an attempt to provide consistency, used  
some scripting which is harder to repurpose in order to hijack the UI. I  
see that as significantly worse. Making something that works would allow  
them to stop doing that.

> 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.

Agreed. Shift-esc is a dreadful modifier for usability - but for the  
people who really seriously benefit such as power users and people who  
cannot use a mouse, having *a* method to get there is better than having  
no implementation, or one that randomly breaks UI.

A visual indicator such as a menu bar entry or some other chrome feature  
is indeed important to making this more generally usable and thus enticing  
authors into learning about it.

>>> - There are barriers to the web app making keyboard shortcuts  
>>> discoverable...

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

So how would the method eventually assigned under your proposal become  
discoverable?

I think we actually agree completely on the discoverability aspect. Opera  
has a pretty weak implementation of discoverability. Sadly, as far as I  
know only iCab (which is in some ways better in some ways worse) actually  
comes close to matching that low level at present - in other words, it's  
the best of an overall woefully poor bunch.

>>> - The set of keys available for shortcuts is not the same across  
>>> different devices...
>>
>> Indeed. But nothing in the syntax and markup as used today requires  
>> that the browser assign that key...
>
> True, but the syntax and markup as used today only allow the content  
> author to make one suggestion to the UA... 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?

Do you think people are likely to use both atttributes in any meaningful  
number of cases? I would suggest that we clarify how to use accesskey with  
more than one character. As AnnevK has already pointed out, the current  
specification and my first proposal are both insufficient on what to do in  
this case anyway. The spec also needs to be clear about how to handle the  
case where two controls have the same shortcut offered. (In a nutshell,  
"make it clear to the user they are different" and then let  
implementations do that the best way they find)

>>> - 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 title attribute is a label that gives extra context, but is not  
generally part of visible UI. I generally see it used (anecdotally - I  
haven't inspected titles in a rigourous way) precisely to provide a label  
that works out of context where the in-context (visible UI) label would  
not be enough.

>> The example Maciej provided is a sadly common one where content is not  
>> very clear about what it does...
>
> 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.

Agreed. But if you added further context information with the title  
attribute, it would satisfy us both, no?

>> For a desktop client it isn't that complicated to [do some
>>   magic to disambiguate repeated controls]
>
> I don't understand how this would work. How can the UA choose which of  
> two natural language labels is "best"?

Badly. This would still be an improvement on having the same label applied  
to two controls that do different things.

> If the action on the control is a script, how would it determine what  
> else (if anything) has the same action?

In the general case it can't - the UA can't fix what the author did. There  
are various specific cases that can be fixed if you want to add more UA  
code or extensions to do so. In accessibility in particular, small overall  
improvements are often of large practical value.

In any case, these are optional repair strategies that apply to either  
proposal, since neither proposal stops the problem arising.

>>> 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.

Right. Like the <access> element.

>> 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.

OK. I am not so convinced that the names are really important. I have  
misunderstood a number of the new HTML 5 proposed elements from their name  
- and a couple of old HTML 4 ones. And my research shows that isn't so  
uncommon. I think that is a semi-technical issue - if we can get the name  
right we save a lot of pain, but otherwise we can spend a lot of time  
arguing about semantics of a term that half the users will never even see,  
in a language that they don't really speak.

I do agree that as a word "command" is a bit more intuitive than "access"  
- especially if we expect all users to take more advantage of keyboard  
shortcuts as a result of improving them.

(Compatibility with XHTML 2 is a higher level question in any case, and  
also a two-way street still).

>>> 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.

For the case where you come up with only one value it seems to provide  
compatibility. For the case where you decide you want two or more, I agree  
- but then it is currently undefined what happens in that case, which  
seems to apply to a bit less than 0.02% of the web, and it would be  
helpful to specify the error handling.

>>> ...in possible combination with one or modifier keys...
>>
>> I strongly suggest implementations do not rely on using a modifier  
>> key...

> I don't think overriding should be allowed...

I don't think anyone who has considered this problem carefully does think  
that.

Interestingly, some authors clearly do want it and work hard to get it. It  
is my hope that a better shortcut mechanism will convince many authors  
that they should play nicely and use it instead. But I realise some will  
continue to try and hijack the UI for various reasons.

> 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.

My experience is different (even with the serious shortcomings in  
discoverability of our current implementation). But this comes down to an  
implementation issue. So long as we don't break the UI (which is  
unfortunately what some current UAs do) I don't see this being anything  
more than a differentiator between browsers.

>>> For traditional desktop UAs that they add a menu to their menu bar or  
>>> a toolbar, with a name like "Commands", "Shortcuts", "Page Shortcuts"
> ...Is there any place in Opera's UI, other than the help file, that I  
> could even find out about the shift-esc shortcut?

No. As I said elsewhere, this is a known problem in our current  
implementation.

>>> For mobile devices with only a numeric keypad available, they could  
>>> assign 0-9, * and # to shortcuts in some order...
>>
>> This is what existing mobile browsers generally do...
>> In fact it makes more sense in many cases to provide an accesskey mode,
(Maybe I should say acceskey menu instead of mode)
...
>
> Once you have to press two keys, it's not nearly as much of a shortcut.

(Well, ctrl-shift-N is three. And having to press them all at once  
seriously reduces the shortcutness of it for people who generally rely on  
sticky keys).

> 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...

In which case, while we disagree on ideal implementation we seem to agree  
on this part of the way forward.

>>> For devices with only touchscreen input and a virtual keyboard...
...
> I am dubious that a UI with hard-to-use in-page actions can be improved  
> with a hidden command mode.

Up to you. It's your browser.

> 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...

I think this is an historical issue. At the time HTML 4 was written, and  
taking into account the implementation advice given (and used), that was  
clearly the best approach. Requiring discoverability and removing the  
ability to suddenly override your UI are the factors taht would change  
that. But IE's first implementation activated most of the controls when it  
hit them and this caused so many probalems for users that they changed it  
to only focus the control in the next version, and the lesson implemented  
at the time was that you should only focus (so as not to surprise your  
users).

...
> 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.

If whatever you can activate has an accesskey/key/shortcutkey/accelerator  
attribute, then you can make it discoverable and use it. I believe we  
agree on this in fact.

>>> - The name of the new attribute is deliberately different than  
>>> "accesskey"
...
>> If you maintained the accesskey name, and instead changed the stupid  
>> implementation advice that is in the HTML 4 spec...
>
> I don't see how your proposal solves the labelling problem,

In the same way yours does, effectively. You can use title on an  
interactive element, you can use title (or label - why the new name?) on  
command/access/pokeAButton, you can use the content of the visible UI.

> the ability to suggest multiple keybindings

It doesn't, but it needs to do so. I think your proposal to allow this  
makes sense - at the very least it describes how to handle errors that  
currently affect about 0.02% of web pages (a bit less than 1% of accesskey  
usage).

> or the desire to have commands that are not tied to visible in-page  
> elements.

The same as yours - by allowing some element like command to assign an  
accesskey.

> I also don't see how it is mutually exclusive with mine, necessarily.

The major compatibility difference is that I propose retaining the name  
and you propose a new attribute. For the rest, I think we are moving along  
virtually the same lines.

>> FWIW We have been doing some research into accesskey usage at Opera...  
>> The most common accesskey is "s"...
>
> 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.

There is nothing in any proposal that suggests anyone would change the "s"  
to something else. (It is recommended in various high-profile guidelines  
for search...)

What we lose by making a clean break is that we have to explain that there  
are now two ways to do the same thing, and decsribe when you should use  
which one.

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 12:34:39 UTC