accesskey=""

After many years of pondering on the issue, I have checked in a definition 
of the accesskey="" attribute.

On Thu, 20 Sep 2007, Maciej Stachowiak wrote:
> 
> 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.

These are good reasons to have a feature for keyboard shortcuts.


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

I have allowed the <command> element to be given an access key, which 
allows any scriptable behaviour to be given a keyboard shortcut.


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

I have provided an API that returns a string representing the keyboard 
shortcut that a particular element has assigned to it, so that scripts can 
expose keyboard shortcuts without having to guess as to the platform 
conventions.

I have also added the right hooks for user agents to provide the feature 
that you propose (not quoted here) for putting the commands into the 
menubar of the application.


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

This is now addressed by those aforementioned hooks, which basically make 
any activatable or focusable element with an accesskey="" attribute into a 
command that can be exposed in a menu.


> - 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 aforementioned DOM attribute now enables this.


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

I have addressed this by making the accesskey="" attribute take a 
space-separated list of characters, and requiring the user agent to use 
the most useful one. For compatibility with legacy UAs, providing just one 
character is naturally still supported, but as user agents support the 
new feature, authors will be able to transition to providing more than 
one shortcut character.

For future extensibility, I have also required tokens with more than one 
character to be ignored for now. We can later add identifiers for various 
purposes, e.g. accesskey="help" to mean that the user agent's default 
"help" key should be used, whatever that is.


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

This is resolved partially by allowing the author to put the accesskey="" 
attribute on the <command> element with a label="" instead of on the 
<button> element (maybe later linking them using the command="" attribute, 
though support for this in the spec is awaiting implementation experience 
with the command system as a whole). It is still possible for authors to 
use accesskey="" on elements without a label, but user agents are not 
required to actually assign a shortcut key if they think the label is not 
going to be useful enough for reuse in the menu.


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

I think the ability to transition by just using one character until most 
browsers support more than one is quite adequate. It's not like this is a 
heavily used feature where it's imperative that the new multiple-key 
feature be available today.


On Thu, 20 Sep 2007, Asbjørn Ulsberg wrote:
> 
> First I have to say that I really like the suggestion. What's missing, 
> though, is a way to bind a command to an actual action in the document. 
> Is this done via a "command" attribute, via scripting, or both?

I've also allowed any other command (e.g. <a>, <input type=button>, etc) 
to be used as a way to set accesskey, which address this. Long term I 
expect we'll allow biding of commands together using an attribute, too.


On Thu, 20 Sep 2007, Adam Roben wrote:
>
> It might be useful to add a DOM attribute to the <command> element that 
> would return the UA's textual representation of the resulting shortcut. 
> This would be useful, for example, if a web app wanted to provide a 
> documentation page that listed all of their shortcuts. The best name 
> I've been able to come up with so far is "computedShortcutKey".

I did this (and called it "accessKeyLabel" so that it would fall by 
"accessKey" in alphabetical lists).


On Fri, 21 Sep 2007, Maciej Stachowiak wrote:
> 
> As stated in my proposal, I don't think the same benefits can be 
> achieved using the accesskey attribute while maintaining compatibility. 
> Just to give an example, let's say I'm writing a web-based mail client 
> with a toolbar offering some common commands. The toolbar button to 
> compose a new message just says [Compose], because in context and with 
> the icon above that seems clear. But I'd like to have the label in a 
> menu listing the shortcut keys to say "Compose New Message", since it is 
> out of context. I'd like it to use some shortcut based on N in clients 
> with a full keyboard, and something based on 1 in clients with only a 
> numeric keypad available. Under my proposal, you'd do it like this:
> 
> <command id="compose" shortcutkey="n 1" label="Compose New Message"
> onclick="compose()">
> 
> <input type="button" value="Compose" onclick="compose()">
> 
> How do you suggest this could be done with accesskey? Note that using 
> space-separated values in accesskey will fail in current UAs, thus 
> removing any backward-compatibility benefits.

You would say just "n" for now, then, when the new feature is wildly 
deployed, you would change it to "n 1". Or alternatively, you would set 
"n" on the <input> element, and "n 1" on the <command>.


> I forgot to mention one other major problem with accesskey. HTML4 says 
> that the effect of activating an accesskey should be to focus the 
> element. But this is very rarely the desired action for a keyboard 
> shorcut. Almost always you want the shortcut to activate something or do 
> some script action. Although the spec seems confused on this point, 
> since it gives some examples of focus that sound more like activation.

I have made HTML5 say that accesskey triggers the command's Action, which 
varies from element to element but is roughly equivalent to clicking it.


On Fri, 25 Jan 2008, Jean-Nicolas Boulay Desjardins wrote:
>
> In the present standard you are alowd to use the same accesskey in to 
> different links... For example:
> 
> <a href="bob.html" accesskey="b">Bob web page</a>
> <a href="bob.html" accesskey="b">Bob web page</a>
> 
> But what would happend if this was to happend:
> 
> <a href="bob.html" accesskey="b">Bob web page</a>
> <a href="alex.html" accesskey="b">Alex web page</a>
> 
> Again this is allowed in the present web standard, but if you think 
> about it its illogical, on what bases thus the browser decide wich one 
> to access first or should it open the tow?

The spec now defines how this works, though it leaves up to the UA the 
decision as to which should get an access key assigned, or whether they 
should both get access keys assigned (but with different modifiers).


On Mon, 28 Jan 2008, Mikko Rantalainen wrote:
> 
> Perhaps the accesskey should be kept but its meaning should be 
> transformed a bit. Instead of being a key (letter) it should be a 
> keyword for a behavior. A good accesskey values could be "home", 
> "index", "search", "contact". The user then could bind the "home" 
> accesskey to any "home" button of his selection. It could be CTRL+H or 
> perhaps F11 instead. Some keyboards have additional "multimedia" keys 
> that could easily be used for such behavior.

I haven't specified this, but I _have_ left room for extending the spec in 
this direction in future, should we find that what we have so far still 
isn't enough.


On Tue, 25 Nov 2008, Olli Pettay wrote:
> 
> FF2, Safari 3.x and Opera 9.6 can activate display:none accesskey targets.
> FF3 changed the behavior to require visible and focusable element.
> IE7 doesn't seem to activate, only focus (at least <a> elements), and
> because hidden element isn't really focusable, it doesn't seem to do anything
> with elements with display:none.

The spec says that accesskey="" only triggers the command if the element 
defines a command that is neither Disabled nor Hidden. Now display:none 
doesn't make a command Hidden (indeed, <command> is display:none by 
default), but accesskey="" itself only defines a command if the element is 
focusable and that only happens if the element is being rendered.

So, long story short, it's defined, but it's not a simple answer.


> A simple testcase https://bugzilla.mozilla.org/attachment.cgi?id=339588

Per spec, those <a> elements are both defining commands that are enabled 
and not hidden, so their access keys should work, and would cause the 
links to be followed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'