is accesskey irretreivably broken as an attribute?

what is broken with accesskey in HTML 4.01?

1. user MUST be able to toggle between accesskey moves focus to associated element, or to have that element activated, in accordance with a user setting; NB: this implies strongly (it might as well be stated) that focus/activate SHOULD: a) provide a toggle as to default action; b) provide an extra modifier (for example, ModifierKey1+Accesskey to focus and ModifierKey2+Accesskey to activate, or ModifierKey1+Accesskey to focus and ModifierKey2+ModifierKey1+Accesskey to activate;
2. user MUST be able to re-assign default modifier keybindings;
3. discoverability of accesskeys -- how to handle? what to mandate? should HTML follow the model set by the Access Element/Module?

what is broken with accesskey in HTML5?

source: http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute

Valid Accesskey Values

in reference to accesskey values, the current draft of HTML5 states:

value must be an ordered set of unique space-separated tokens, each of which must be exactly one Unicode code point in length.

PROBLEM:

1. accesskeys SHOULD be drawn from the charset used to render the natural language of the document in which they appear; an accesskey SHOULD be defined as a single character one Unicode code point in length from the document character set;

psuedo-cascade of multiple accesskeys definable for individual element

1. one can provide a "cascade" of accesskeys for an individual element using a space delimited list; to take the example currently in the HTML5 draft:

[...] the search field is given two possible access keys, "s" and "0" (in that order). A user agent on a device with a full keyboard might pick Ctrl+Alt+S as the shortcut key, while a user agent on a small device with just a numeric keypad might pick just the plain unadorned key 0:

<form action="/search">
 <label>
 Search: <input type="search" name="q" accesskey="s 0">
 </label>
 <input type="submit">
</form>

PROBLEMS:

1. cascade order is a very "weak" rather than a strong binding -- how does the user know what accesskey to use when multiple accesskeys are assigned to an individual element?
2. "limited group of characters" -- there are a very finite number of characters that one can use as an accesskey; is the cascade of keys set using a space delimited list global? (that is, does every first item listed belong to accesskey-scheme A, the second to accesskey-scheme-B, etc.

<form action="/search">
 <label>Search: <input type="search" name="q" accesskey="s 0"></label>
 <input type="submit" accesskey="= 1">
</form>

in the preceding code sample, is the first accesskey theme:

1. accesskey for input type="search" = s
2. accesskey for input type="submit" = =

(for fellow speech users, the first acesskey is the character s while the second is the equals-sign)

and the second:

1. accesskey for input type="search" = 0
2. accesskey for input type="submit" = 1

(for fellow speech users, the first acesskey is the character 0 while the second is the character 1)

if so, this needs to be explicitly stated in the HTML5 spec.

HTML5 hard-binds "Action" to accesskey key-press

source: http://dev.w3.org/html5/spec/commands.html#command-facet-action

When the user presses the key combination corresponding to the assigned access key for an element, if the element defines a command, and the command's Hidden State facet is false (visible), and the command's Disabled State facet is also false (enabled), then the user agent must trigger the Action of the command.

this is at variance with the Access Module/Element's architecture, which provides a boolean attribute "activate" which allows an author to set the AccessKeyPress to either move focus to the object for which the accesskey is defined (activate="no") or whether the AccessKeyPress results in the activation of the element to which the accesskey has been assigned (activate="yes")

the Access Module/Element's activate attribute also provides the following, which is lacking in the HTML5 draft:

User agents MUST provide mechanisms for overriding the author setting with user-specified settings in order to ensure that the act of moving content focus does not cause the user agent to take any further action (as per Checkpoint 9.5 of UAAG 1.0)