Re: Proposal for Keyboard Shortcuts for HTML5

Hi Maciej,

On Sep 20, 2007, at 6:03 AM, Maciej Stachowiak wrote:

>
> 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 think the Wiki proposal addresses much more of the shortcomings of  
accesskey:[1]

It's is not really clear what use case the command element addresses.  
I think it has significant overlap with 'select',, 'datalist',  and  
'menu'. I don't think we should be adding so many elements to the  
document conformance without thinking about the severe overlap in  
their semantics and trying to make better sense out of it. As for the  
proposed 'shortcutkey' attribute it might make sense to add it to  
'option', 'li' and others.

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

I think NCNames would be more appropriate for this. If we're going to  
address the short-comings of accesskey, why not address as many as we  
can.

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

Again, I'm not sure why we need another separate element to create  
menus, checkboxes and radio buttons (I guess the command element also  
overlaps with the input element).

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

Again, I think the NCName works better for this than using a  
character data type.

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

 From this example, its not clear what the command element brings to  
the situation. If compose new message were attached to a hyperlink,  
then doesn't the hyperlink already define the command?

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

This is less related to the shortcut key proposal, but if authors are  
looking to create a menu of shortcuts wouldn't the datalist or select  
elements be a more appropriate place fro this attribute. That would  
give authors complete control over the structure of their shortcut  
menus and still allow the assignment of a shortcut key.

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

Native desktop applications also allow the specification of modifier  
keys. Also, I think we need to take into account the broad  
environments that web applications have to run in and the wiki  
proposal better addresses that.

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

If it still uses a character data type rather than a NCName, I think  
its subject to many of the same limitations of the current accesskey  
(and XHTML2's access@key).

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

Moving away from the accesskey name is a good first step,  but its  
insufficient.


Take care,
Rob

[1]: <http://esw.w3.org/topic/HTML/KeyBindingMarkup>

Received on Saturday, 22 September 2007 04:01:11 UTC