Re: Proposal for Keyboard Shortcuts for HTML5

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", 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:

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? That way users could get a much more
consistent-across-sites experience, and authors wouldn't be burdened with
having to be aware of all the possible different sorts of browsing
environments out there today (not to mention those of the future).

Sure, for a web mail client, some users might actually use it that often that
they'll get used to the keyboard sortcuts of that one site. But I suspect
they'd be an awfully small group of people. If the same key combo works
across sites, it would be picked up by many more users. It would also be a
much bigger incentive for authors, which in turn would mean more users are
being served.

(I haven't really thought about what syntax this would require. @role might
be appropriate, but I'm just going by its name; I haven't looked into @role.)

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". I'm not sure what might be a good approach
to handle that. Possibly the old @accesskey can be upgraded to serve those
special cases. But even there I'm not sure... I used to be an @accesskey
advocate, but in the last few years I've gotten more and more convinced that
it just isn't a good idea at all to let authors define key combos. That's the
exact opposite of what I advocated at
<http://www.euronet.nl/~tekelenb/WWW/LINK/> (where the main point is
"consistency across sites"). So perhaps better would be to also have one
generic "role" that authors use for non-predefined "roles", and let UAs
assign 'any' key combo to that that is still available.

[...]

>> 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. A keyboard shortcut mode would
> not be acceptable by Apple's standards of usability.

F12 ;)

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? Just like Mac OS X's Action Menu
has made the functionality of the contextual menu much more discoverable.)

Btw, I'm sure you're aware of iCab's accesskey implementation: showing the
@accesskey value right after the element. Very discoverable, except it
doesn't tell the user what it indicates. Perhaps with some imagination UAs
could present it somehow in a way that is more recognisable as indicating a
keyboard shortcut. By inserting Cmd and Shift icons; displaying a small icon
of a keyboard on hover; something along those lines. Maybe even just a simple
little bit of default CSS: *[accesskey]:after {content: " Ctrl-"
attr(accesskey); font-weight: bold}

[... overriding native key combo's]

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

If you visit with Opera, you need to know to hit Shift-Esc to get a floating
window listing all accesskeys and their 'labels'. Just type the accesskey
value, without any modifier key, to 'access' the element (I don't understand
why items in that floating window aren't mouse-clickable).

If you visit with iCab, make sure that in its prefs you have accesskey
support switched on. (These days it is off by default -- another hint that
author-defined key combo's aren't a great idea) Everything marked up with
@accesskey will have its value listed behind it, in superscript, enclosed in
brackets. Type Ctrl-<key> to 'access' the element.

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


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Saturday, 22 September 2007 06:01:02 UTC