Re: Proposal for Keyboard Shortcuts for HTML5

Hi Charles,

I just joined the HTML working group. Regarding accesskey, Has the group
looked at using a modified version of the access element from xhtml 2 which
supports device independence?

This is an editors draft of the access element pulled out of xhtml 2 and
targeted for XHTML 1.X  markup. It allows for device independence as well.

http://www.w3.org/MarkUp/2007/ED-xhtml-access-20070905/


Cheers,

Rich


Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review  Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer



                                                                           
             "Charles                                                      
             McCathieNevile"                                               
             <chaals@opera.com                                          To 
             >                         "Maciej Stachowiak"                 
             Sent by:                  <mjs@apple.com>,                    
             public-html-reque         "public-html@w3.org WG"             
             st@w3.org                 <public-html@w3.org>                
                                                                        cc 
                                                                           
             09/21/2007 05:44                                      Subject 
             AM                        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)