Re: Proposal for Keyboard Shortcuts for HTML5

Summary: I think the proposal makes sense in many aspects. I support the  
substance as "we need to fix keyboard shortcuts" and some of the details  
proposed (and have even made some of them to this group before [1][2]).

But I don't support introducing a new attribute. I think this proposal  
needlessly reinvents wheels rather than paving cowpaths, breaks backward  
compatibility, fails to resolve an existing problem with accesskeys (that  
IMHO is an implementation bug that has nothing to do with the markup spec  
and everything to do with poor implementation advice that was given in the  
HTML 4 spec), and makes assumptions about how accesskey can be implemented  
that are much more limited than even existing implementations.

The good stuff in this proposal can be applied directly to the accesskey  
attribute as it exists, leading to better, backwards-compatible  
implementations, while minimising the need to change all the guidance  
given and tools developed so far and obviating the need for a new  
attribute.

Details below...

On Thu, 20 Sep 2007 13:03:03 +0200, Maciej Stachowiak <mjs@apple.com>  
wrote:

> Keyboard shortcuts are useful for a number of reasons:
[some reasons]
> 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.

This is indeed a problem of accesskey.

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

This is an implementation issue. In Opera, if you activate accesskey mode  
(shift-esc is our current default, which I agree is non-intuitive. I remap  
it to one of the find-as-you-type shortcuts) then you see all the things  
that have accesskey. It would be helpful if there were an indicator that  
there is something there, but that's not a big deal.

In mobile implementations that I have used they generally do insert  
content - but these have been low-end mobile devices that don't do much  
presentation anyway. Showing, in high-end devices, that there is something  
there if you activate accesskey mode is not asking for a huge amount of  
real estate.

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

Indeed. This is not a barrier to doing it though, it is a very good reason  
why the web app typically should not do it. Poor implementation until now  
has meant that authors have tried to tell users what the key is since  
otherwise there is literally no way of knowing, in some popular browsers,  
that your common shortcuts have been "hijacked".

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

Indeed. But nothing in the syntax and markup as used today requires that  
the browser assign that key. Indeed, several middle-ware or  
extension-based implementations explicitly provide for re-mapping to  
something more useful for a given platform.

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

There are several indicators that can be used. The content of a control  
(e.g. the text of a link, or an image used in a link) and the value of the  
title attribute are the most obvious. For form controls, the value of a  
<label> element. The example Maciej provided is a sadly common one where  
content is not very clear about what it does - a similar example is  
several controls labelled "click here". (There's a reason why WAI has been  
asking people not to do that for years - and a number of people got the  
message, though not all). For a desktop client it isn't that complicated  
to extract what the control activates, check whether anything else  
activates that control and whether anything that activates a different  
control has the same default label, and then use a heuristic to select the  
"best" label available. This could be written into an extension in userJS  
or similar. But you probably wouldn't want to run it on your phone - there  
it would be better built into a proxy...

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

This seems similar to the access element in XHTML 2. Maybe it would be  
better to give it the same name, and just improve the definition. Or is  
there some reason for being different that I have missed?

> I propose that the command element be given a new attribute, shortcutkey.

Why not call the attribute "key" (for comaptibility with XHTML2) or  
"accesskey" for compatibility with the Web?

> 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, [...]
> If none of the suggestions is available, the UA should assign a keyboard  
> shortcut as if the value were empty.

This is close to my accesskey proposal [1] but has an advantage in  
clarifying that you can have more than one character. A further  
clarifications that should be added:

  User agents should assign a unique control (e.g. key value) to each  
unique action. (Which answers the question "what happens if you have two  
controls with the same accesskey?" that is currently unspecified in HTML).

> in possible combination with one or modifier keys.

I strongly suggest implementations do not rely on using a modifier key as  
an accesskey mechanism. In most uesr agents today users expect a  
particular behaviour from modifier-plus-key for a number of combinations  
(as noted in the original mail), and overriding those makes for  
unpredictable behaviour. Indeed, the single biggest real problem with  
accesskey as implemented in Netscape, Firefox prior to version 2 and IE is  
that they override existing keys that users rely on.

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

This is roughly how Opera implemented accesskey.

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

This is what existing mobile browsers generally do (except that most of  
them rely on those characters being specified as the accesskey already).  
In fact it makes more sense in many cases to provide an accesskey mode,  
the same as I suggest for desktop, since modern phone browsers use the raw  
keypad for a number of handy functions like moving the cursor, going to  
the top of the page, etc, to avoid requiring too much menu navigation for  
common functions.

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

Alternatively, it may make sense to do what Opera does on desktop: When  
you activate accesskey mode (which would be with a gesture) you get the  
menu that just contains the things that have accesskeys assigned. On a  
large page which would have required scrolling around to find the bit you  
want, then hitting the control, this may be quicker for common actions.

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

In markup terms it is introducing a compulsory indirection. accesskey in  
HTML 4 didn't have that idea, but if you have a command element to provide  
the indirection as desired there is no reason I can see not to simply  
extend the applicability of accesskey to that element.

As far as I can see, the biggest value of the command element is that it  
solves the first problem you mentioned - that you can then assign a  
command to increasing the value on a slider, rather than just having one  
default action for a slider.

It is also known ("proven" by a significant preponderance of evidence)  
that changing established shortcuts is not helpful to users. So relying on  
modifier keys in a situation like the diversity of the Web, where the  
combinations are likely to conflict with other functions, is generally not  
helpful implementation advice.

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

I think you have seriously underestimated how a decent implementation of  
accesskey would behave. Your proposal has a lot in common with my proposed  
suggestions [2], but there are further possibilities (some repeated in  
this mail) that could enhance the usefulness of a keyboard shortcut  
mechanism. As a design goal, my proposal maintained compatibility with the  
existing Web, and I deliberately avoided introducing anything new. (I  
assume that accesskey should "obviously" be applied to any element like  
command/xhtml2:access - but maybe I should be more explicit about that).

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

yes.

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

Except as used by the "accessibility" community, accessibility on the web  
is generally understood to cover issues that relate to whether users can  
get to something or not. The specificity of covering people with  
disabilities isn't part of english anyway. (Change the language and the  
whole notion vanishes anyway).

If you maintained the accesskey name, and instead changed the stupid  
implementation advice that is in the HTML 4 spec, along the lines I  
proposed a few months ago [1] then you would in fact have the semantics  
you are looking for, plus compatibility with existing markup (and with the  
horrible implementations in some current browsers).

FWIW We have been doing some research into accesskey usage at Opera. I  
hope that we will be able to publish enough information to make this  
reproducible by anyone, but I can't promise anything yet. On a survey of  
about a million pages, accesskey is used in about 1% of them and it is  
used "right" according to the HTML 4 spec requirements, that is as a  
single character, a bit more than 99% (less than 99.5%) of the time. The  
most common accesskey is "s" and the keys listed by the UK government  
guidelines for their own websites (which have been taken up in other  
countries and in other languages - other than "s" they use digits which is  
nice for phones) seem to account for the majority of all keys assigned.

[1] http://lists.w3.org/Archives/Public/public-html/2007Jul/0185.html
[2] http://lists.w3.org/Archives/Public/public-html/2007Jul/0213.html is  
the

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 Friday, 21 September 2007 10:45:21 UTC