Proposal for Keyboard Shortcuts for HTML5

Hi everyone,

Keyboard shortcuts are useful for a number of reasons:

- They are important to usability of normal desktop applications. The  
typical native application includes a number of keyboard shortcuts and  
experienced users often make use of them in preference to the mouse or  
tab cycling. For instance, many Mac OS X desktop applications feature  
Cmd-Z as a keyboard shortcut for undo, and this is faster than picking  
the command from a pull-down menu.

- Keyboard shortcuts can be an aid to accessibility for users who  
cannot readily operate a pointing device such as a mouse, due to motor  
or vision difficulties.

- Many mobile devices have a pointing device that is very awkward for  
anyone to use.


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.

- 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.  
Putting a marker on elements with an accesskey value at all times  
messes with the appearance of the page as intended by the designer of  
the page. 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.

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

- 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. For example, 0-9 are the only keys  
that could reasonably be available on a mobile phone with only a  
numeric keypad. But in Safari on Mac OS X, 0-9 with the normal  
modifier key for keyboard shortcuts are taken by the browser itself.

- 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. For example, <http://www.amazon.com/> has two buttons  
labelled "Go" at the very top, one of which performs an Amazon search  
and the other of which performs a Web search. I'm not sure either of  
these buttons is a great choice for a keyboard shortcut, but if there  
were a list giving their shortcuts you'd really want the labels in the  
list to be "Search Amazon" and "Search the Web" respectively, not "Go".


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.  
It has a label attribute which can provide a label that can work  
reasonably well in a standalone context. It also defines ways that  
some other elements can act as commands.

I propose that the command element be given a new attribute,  
shortcutkey. 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, in possible combination with one or modifier  
keys. If none of the suggestions is available, the UA should assign a  
keyboard shortcut as if the value were empty.

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.

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.

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.


Example:

A web mail client could include the following in the markup to support  
a keyboard shortcut for "compose new message":

<command label="Compose New Message" shortcutkey="n 1">

This would request a combination with N or 1 in that preference order,  
which might be mapped to Cmd-Shift-N on the Mac browsers, (since Cmd-N  
is likely to be taken by the browser for New Window), Ctrl-Alt-N on  
Windows browsers, N on mobile devices with a full keyboard, and 1 on  
mobile devices with only a numeric keypad.

If a Mac Browser were to have the suggested Page Shortcuts Menu, it  
might display "Compose New Message ^%N", where ^ and % are my  
representations of the up-arrow and cloverleaf characters that would  
actually be used to avoid sending non-ASCII email to the list.


Notes:

- This is much closer than accesskey="" to the way keyboard shortcuts  
work in native desktop applications, a proven and effective model.

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

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

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


Comments welcome.

Regards,
Maciej

Received on Thursday, 20 September 2007 11:03:18 UTC