<op.tyz2s3hlwxe0ny@widsith.local>
Current votes: None.
Summary: I think the proposal makes sense in many aspects. I support the =
=20
substance as "we need to fix keyboard shortcuts" and some of the details =
=20
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 =20
needlessly reinvents wheels rather than paving cowpaths, breaks backward =
=20
compatibility, fails to resolve an existing problem with accesskeys (that=
=20
IMHO is an implementation bug that has nothing to do with the markup spec=
=20
and everything to do with poor implementation advice that was given in th=
e =20
HTML 4 spec), and makes assumptions about how accesskey can be implemente=
d =20
that are much more limited than even existing implementations.
The good stuff in this proposal can be applied directly to the accesskey =
=20
attribute as it exists, leading to better, backwards-compatible =20
implementations, while minimising the need to change all the guidance =20
given and tools developed so far and obviating the need for a new =20
attribute.
Details below...
On Thu, 20 Sep 2007 13:03:03 +0200, Maciej Stachowiak <mjs@apple.com> =20
wrote:
> Keyboard shortcuts are useful for a number of reasons:
[some reasons]
> HTML 4.01 has a feature for keyboard shortcuts, the accesskey=3D"" =20
> attribute. But it has many problems:
>
> - It is tied to a specific control in the page. But in native =20
> applications, many keyboard shortcuts do not have a direct one-to-one =20
> correspondence with a specific control element. For example, you may =20
> want a shortcut to focus an element that is also capable of activating,=
=20
> or vice versa, but accesskey can't let you choose which to do. Or you =20
> may want increment and decrement commands where the in-page UI is a =20
> slider control.
This is indeed a problem of accesskey.
> - Keyboard shortcuts are not discoverable. It's not obvious looking at =
a =20
> web application whether it even has keyboard shortcuts, let alone what =
=20
> they are.
>
> - There are barriers to the UA making keyboard shortcuts discoverable.
This is an implementation issue. In Opera, if you activate accesskey mode=
=20
(shift-esc is our current default, which I agree is non-intuitive. I rema=
p =20
it to one of the find-as-you-type shortcuts) then you see all the things =
=20
that have accesskey. It would be helpful if there were an indicator that =
=20
there is something there, but that's not a big deal.
In mobile implementations that I have used they generally do insert =20
content - but these have been low-end mobile devices that don't do much =20
presentation anyway. Showing, in high-end devices, that there is somethin=
g =20
there if you activate accesskey mode is not asking for a huge amount of =20
real estate.
> - There are barriers to the web app making keyboard shortcuts =20
> discoverable. The web app does not know what modifier keys the UA will =
=20
> add, if any, so it cannot display the true shortcut in the page or in =20
> help materials.
Indeed. This is not a barrier to doing it though, it is a very good reaso=
n =20
why the web app typically should not do it. Poor implementation until now=
=20
has meant that authors have tried to tell users what the key is since =20
otherwise there is literally no way of knowing, in some popular browsers,=
=20
that your common shortcuts have been "hijacked".
> - The set of keys available for shortcuts is not the same across =20
> different devices, operating systems and browsers, but the syntax for =20
> accesskey requires choosing one.
Indeed. But nothing in the syntax and markup as used today requires that =
=20
the browser assign that key. Indeed, several middle-ware or =20
extension-based implementations explicitly provide for re-mapping to =20
something more useful for a given platform.
> - The UA may wish to present a list of available keyboard shortcuts to =
=20
> the user in some sort of list, but there may not be a good label =20
> available. All the UA can use is the label of the control, but a label =
=20
> that's good in the context of the page may not be very good in an out-=20
> of-context list.
There are several indicators that can be used. The content of a control =20
(e.g. the text of a link, or an image used in a link) and the value of th=
e =20
title attribute are the most obvious. For form controls, the value of a =20
<label> element. The example Maciej provided is a sadly common one where =
=20
content is not very clear about what it does - a similar example is =20
several controls labelled "click here". (There's a reason why WAI has bee=
n =20
asking people not to do that for years - and a number of people got the =20
message, though not all). For a desktop client it isn't that complicated =
=20
to extract what the control activates, check whether anything else =20
activates that control and whether anything that activates a different =20
control has the same default label, and then use a heuristic to select th=
e =20
"best" label available. This could be written into an extension in userJS=
=20
or similar. But you probably wouldn't want to run it on your phone - ther=
e =20
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 =20
> 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 =20
better to give it the same name, and just improve the definition. Or is =20
there some reason for being different that I have missed?
> I propose that the command element be given a new attribute, shortcutke=
y.
Why not call the attribute "key" (for comaptibility with XHTML2) or =20
"accesskey" for compatibility with the Web?
> The value is either empty or a space-separated list of characters. If =20
> the value is empty, the UA can assign any shortcut key combination it =20
> wants. If a list is provided, the UA should use that as a list of =20
> suggestions from most preferred to least preferred for a key that shoul=
d =20
> be assigned, [...]
> If none of the suggestions is available, the UA should assign a keyboar=
d =20
> shortcut as if the value were empty.
This is close to my accesskey proposal [1] but has an advantage in =20
clarifying that you can have more than one character. A further =20
clarifications that should be added:
User agents should assign a unique control (e.g. key value) to each =20
unique action. (Which answers the question "what happens if you have two =
=20
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=
=20
an accesskey mechanism. In most uesr agents today users expect a =20
particular behaviour from modifier-plus-key for a number of combinations =
=20
(as noted in the original mail), and overriding those makes for =20
unpredictable behaviour. Indeed, the single biggest real problem with =20
accesskey as implemented in Netscape, Firefox prior to version 2 and IE i=
s =20
that they override existing keys that users rely on.
> For traditional desktop UAs that they add a menu to their menu bar or a=
=20
> toolbar, with a name like "Commands", "Shortcuts", "Page Shortcuts" or =
=20
> similar, which includes the commands with their labels and the keyboard=
=20
> shortcuts assigned by the UA. Check or radio commands could create chec=
k =20
> or radio menu items.
This is roughly how Opera implemented accesskey.
> For mobile devices with only a numeric keypad available, they could =20
> assign 0-9, * and # to shortcuts in some order and optionally display a=
=20
> list of shortcuts with labels below the bottom of the page.
This is what existing mobile browsers generally do (except that most of =20
them rely on those characters being specified as the accesskey already). =
=20
In fact it makes more sense in many cases to provide an accesskey mode, =20
the same as I suggest for desktop, since modern phone browsers use the ra=
w =20
keypad for a number of handy functions like moving the cursor, going to =20
the top of the page, etc, to avoid requiring too much menu navigation for=
=20
common functions.
> For devices with only touchscreen input and a virtual keyboard, it may =
=20
> make sense to have no interface at all for keyboard shortcuts since =20
> using a virtual keyboard is unlikely to be faster or easier than =20
> interacting with the page directly.
Alternatively, it may make sense to do what Opera does on desktop: When =20
you activate accesskey mode (which would be with a gesture) you get the =20
menu that just contains the things that have accesskeys assigned. On a =20
large page which would have required scrolling around to find the bit you=
=20
want, then hitting the control, this may be quicker for common actions.
> Notes:
>
> - This is much closer than accesskey=3D"" to the way keyboard shortcuts=
=20
> work in native desktop applications, a proven and effective model.
In markup terms it is introducing a compulsory indirection. accesskey in =
=20
HTML 4 didn't have that idea, but if you have a command element to provid=
e =20
the indirection as desired there is no reason I can see not to simply =20
extend the applicability of accesskey to that element.
As far as I can see, the biggest value of the command element is that it =
=20
solves the first problem you mentioned - that you can then assign a =20
command to increasing the value on a slider, rather than just having one =
=20
default action for a slider.
It is also known ("proven" by a significant preponderance of evidence) =20
that changing established shortcuts is not helpful to users. So relying o=
n =20
modifier keys in a situation like the diversity of the Web, where the =20
combinations are likely to conflict with other functions, is generally no=
t =20
helpful implementation advice.
> - The proposed model provides mode device-independence and =20
> discoverability than accesskey does, either as implemented today or in =
=20
> the best possible case in my opinion.
I think you have seriously underestimated how a decent implementation of =
=20
accesskey would behave. Your proposal has a lot in common with my propose=
d =20
suggestions [2], but there are further possibilities (some repeated in =20
this mail) that could enhance the usefulness of a keyboard shortcut =20
mechanism. As a design goal, my proposal maintained compatibility with th=
e =20
existing Web, and I deliberately avoided introducing anything new. (I =20
assume that accesskey should "obviously" be applied to any element like =20
command/xhtml2:access - but maybe I should be more explicit about that).
> - Assistive technologies generally know how to scan and operate =20
> application menu bars, so on desktop systems the commands would likely =
=20
> automatically be exposed to AT as well.
yes.
> - The name of the new attribute is deliberately different than =20
> "accesskey", since the semantics and allowed values are different. This=
=20
> makes it possible in theory for a page to use both accesskey and =20
> shortcutkey on the same element, if we end up allowing them on the same=
=20
> elements; they could have some level of keyboard access in older UAs bu=
t =20
> get the better new model in HTML5 UAs. I also think "shortcut key" is a=
=20
> better name, since keyboard shortcuts exist for all users, not just for=
=20
> accessibility purposes.
Except as used by the "accessibility" community, accessibility on the web=
=20
is generally understood to cover issues that relate to whether users can =
=20
get to something or not. The specificity of covering people with =20
disabilities isn't part of english anyway. (Change the language and the =20
whole notion vanishes anyway).
If you maintained the accesskey name, and instead changed the stupid =20
implementation advice that is in the HTML 4 spec, along the lines I =20
proposed a few months ago [1] then you would in fact have the semantics =20
you are looking for, plus compatibility with existing markup (and with th=
e =20
horrible implementations in some current browsers).
FWIW We have been doing some research into accesskey usage at Opera. I =20
hope that we will be able to publish enough information to make this =20
reproducible by anyone, but I can't promise anything yet. On a survey of =
=20
about a million pages, accesskey is used in about 1% of them and it is =20
used "right" according to the HTML 4 spec requirements, that is as a =20
single character, a bit more than 99% (less than 99.5%) of the time. The =
=20
most common accesskey is "s" and the keys listed by the UK government =20
guidelines for their own websites (which have been taken up in other =20
countries and in other languages - other than "s" they use digits which i=
s =20
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 =
=20
the
cheers
Chaals
--=20
Charles McCathieNevile, Opera Software: Standards Group
hablo espa=C3=B1ol - je parle fran=C3=A7ais - jeg l=C3=A6rer norsk
chaals@opera.com http://snapshot.opera.com - Kestrel (9.5=CE=B11)