Re: Proposal for Keyboard Shortcuts for HTML5

On Sat, 22 Sep 2007 07:52:33 +0200, Sander Tekelenburg <st@isoc.nl> wrote:

> At 18:05 -0700 UTC, on 2007-09-21, Maciej Stachowiak wrote:
>> On Sep 21, 2007, at 3:44 AM, Charles McCathieNevile wrote:
> [...]
>> 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"...

> Sounds awfully semantic to me. Wouldn't it be better if HTML would allow
> authors to mark up such *meanings*, and leave it up to the UA to provide  
> the appropriate keyboard shortcut?...

This is indeed the sort of thing that @role is designed for - and in  
particular the extensibility of @role was meant to cope with such a case.

If the UA has no idea what the role is, then it is helpful if the author  
has requested a shortcut (or 6) that the UA can use as a mnemonic if it is  
available in some way.

> The main problem with this would be that with a predefined set of such
> "roles", there could still be cases where authors wish to provide  
> keyboard access to non-predefined "roles".

The current design of role allows for this with extensibility. But there  
is a proposal on the table with a lot of support that in order to have  
@role in HTML 5 it would lose the xtensibility

> Possibly the old @accesskey can be upgraded

Well, it could just be used. It doesn't provide much useful info, but it  
does provide some.

> it just isn't a good idea at all to let authors define key combos.

I think everyone who has though about this recognises that the author's  
suggestion should not be automatically followed, since it may introduce  
conflicts.

>>> On Thu, 20 Sep 2007 13:03:03 +0200, Maciej Stachowiak
>>> <mjs@apple.com> wrote:
>
> [... Shift-Esc to enter accesskey mode in Opera]
>
>> 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.

What you get with the accesskey mode in OPera is a shortcut that opens  
such a menu. Instead of being on the toolbar it is on the screen.

> But yeah, I agree. Such "modes" won't reach many users, and thus not  
> motivate many authors. (However, who's to say that a UA couldn't have
> a shiny magical button in its toolbar to enter that mode?...)

Indeed, it is helpful to have an indication in the chrome that you can  
activate this mode. And it would be useful if it had an easy-to-use  
shortcut, as well as being easy to navigate to, and being mouse  
activatable.

> Btw, I'm sure you're aware of iCab's accesskey implementation: showing  
> the @accesskey value right after the element.

Yep. That worked when iCab had all the keys available without a modifier,  
since they had no other function in the UI. Unless you use something  
perfectly legitimate like Æ (AE ligature) (it's a key on my keyboard, it's  
a letter in several alphabets, and it's mnemonic for a bunch of things.  
But it isn't on most keyboards that support ش (arabic character shad).  
Nor, for that matter, is "N")

>> I don't think overriding should be allowed.
>
> Agreed.
>
> [...]
>
>>> 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>

Correct. That's a usability bug in our current implementation.

> If you visit with Opera, ...(I don't understand why items in that  
> floating window aren't mouse-clickable).

It's another usability bug. (These have been filed by the way, but bugs  
don't all vanish at once :( )

> [... "s" and digits fond to be most commonly used accesskey values]
>
>> 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.
>
> I tend to agree, and think this is a strong argument for providing a  
> means to semantically indicate an element's function, and let the UA
> assign the appropriate key combo; not leave that to authors.

It is. It is also a strong argument for doing something other than using  
common system modifiers to activate shortcut keys.

The more powerful a set of commands you have available in your browser and  
OS, the fewer keys are available through common shortcut mechanisms. Ditto  
for the fewer keys you have on your device. Asking authors to try and  
further load that space has drawbacks as well as benefits - the most  
obvious one being that you will be much more likely to have conflicts and  
leave the UA guessing what to use.

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 11:09:05 UTC