Re: Proposal for Keyboard Shortcuts for HTML5

On Sep 21, 2007, at 10:52 PM, Sander Tekelenburg wrote:

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

It might be useful to do this for common commands, but many  
interesting application commands are not common to other types of  
applications, so are unlikely to be predefined. Some that are broadly  
interesting, like cut/copy/paste, are predefined by the UA.

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

Well, shortcuts have the most value either when they apply to an  
application you use a lot, or when they apply to many different kinds  
of applications. For individual applications that get used a lot, the  
common operations are likely to include some of the unique ones. So  
even if we find some set of operations that could get common  
shortcuts, I think a normal shortcut key facility would still be useful.

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

Sounds complicated to me.

> [...]
>
>>> 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 ;)

(For those who aren't Mac users, F12 is the global keyboard shortcut  
to enter the Dashboard, which is a mode that displays widgets.) F12  
isn't really analogous, since it's a shortcut for the more obvious way  
to enter Dashboard, using the Dock icon.

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

Sure, that's possible, but I think making the menu just show the  
commands and shortcuts, so you can later use them without the menu,  
would be considerably nicer. Also, a mouse-clickable button to  
activate keyboard shortcut mode seems to miss the point of keyboard  
shortcuts.

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

I wasn't aware of it, and I don't see it working in iCab 3.0.3. This  
is my test case: <input accesskey="a">


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

A CSS-based approach would not combine well with the idea that the UA  
should reassign shortcuts to avoid conflicts. In general adding stuff  
to the visible page contents is likely to discourage authors from  
using the feature. I think the menu idea I suggested (and similar idea  
suggested by Chaals) is a better approach to discoverability.

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

I did try shift-esc, but I don't know how I could have possibly known  
about it without being told. I also see a lot of (null) labels in the  
gadget that pops up.

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

Using a non-default preference setting doesn't sound like a win for  
discoverability either.

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

I'm dubious, mainly because I don't think a reasonable-sized list  
could cover enough commands to work for a wide range of web apps.  
Giving a label and some preferred key choices, with the option for the  
UA to pick something else in case of conflict, seems like it will do  
well enough in most cases.

Regards,
Maciej

Received on Saturday, 22 September 2007 07:07:54 UTC