issues with global attribute "accesskey" as-is in HTML5

aloha!

what follows is a list of issues with the accesskey attribute as 
defined in the current editor's draft of HTML5

when the HTML5 draft was submitted to the W3C by the WHAT WG, the 
accesskey attribute had been removed;

http://www.w3.org/html/wg/wiki/DroppedAttributeAccesskey

the accesskey attribute was, however, subsequently re-added to HTML5, 
so this post is a discussion of the global attribute "accesskey" as it 
currently appears in the HTML5 draft:

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

ISSUE 1. is accesskey irretrievably broken as an attribute?

is an attribute (@accesskey) sufficient to provide the needed 
functionality or should the element approach outlined in the Access 
Module/Element (which has the advantage of having been vetted and 
modified due to feedback provided by the WAI, UAAG and SVG WGs) be 
championed by the A11y TF?

further discussion at:
* http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/access_key_requirements

ISSUE 2. Valid Accesskey Values

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

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

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

ISSUE 3. Psuedo-Cascade of Multiple Accesskeys Definable for an Individual
       Element

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:

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

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

PROBLEM 3.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?

PROBLEM 3.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:

 A. accesskey for input type="search" = 0
 B. 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.

ISSUE 4. HTML5 hard-binds "Action" to accesskey key-press:

QUOTE src="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.
UNQUOTE

PROBLEM 4.1. 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")

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

QUOTE src="http://www.w3.org/TR/xhtml-access/#sec_3.1.1."
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)
UNQUOTE

REFERENCES:

Reference 1. PF's initial feedback to HTML WG July 2007:
* http://lists.w3.org/Archives/Public/public-html/2007Jul/0903.html

QUOTE 
Outside of ARIA we would like HTML 5 to support the XHTML access 
element. The access element supports badly needed semantics for 
access key navigation but without the need for device dependency 
restrictions.
UNQUOTE

for references to accesskey in WCAG 1.0 and 2.0, please consult:
* http://www.w3.org/WAI/PF/HTML/wiki/Access#Accesskey

Reference 2. is accesskey irretreivably broken as an attribute?
* http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/access_key_requirements

Reference 3. accesskey in HTML5 (global attribute)
* http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute

Reference 4. Last Public Draft of Access Module: 
* http://www.w3.org/TR/xhtml-access/

Reference 6. Last Editor's Draft of Access Module: 
* http://www.w3.org/MarkUp/2009/ED-xhtml-access-20090423

Reference 7. "The Access Element: Enabling Generic Document Accessibility" 
[PFWG Proposed Internal Draft, 2010-05-19]
*
http://lists.w3.org/Archives/Public/www-archive/2010May/att-0020/access-element-20100519.html

QUOTE
source: http://lists.w3.org/Archives/Public/www-archive/2010May/0020.html

[The Access Element draft] is intended to provide a starting point for 
work on the Access Element, based on the Last Call Draft of the XHTML 
Access Module

http://www.w3.org/TR/2008/WD-xhtml-access-20080526

and the subsequent editor's draft which reflected refinements to the 
Last Call draft due to feedback received during Last Call:

http://www.w3.org/MarkUp/2009/ED-xhtml-access-20090423

Although this document is a PROPOSED first editor's draft, it is based on 
the Last Call Working Draft of the XHTML Access Module, produced by the 
XHTML 2 Working Group. The XHTML Access Module has been used as the basis 
of this document, as the XHTML Access Module reflects a consensus among 
the members of the XHTML2 Working Group, in conjunction with extensive 
input from the User Agent Accessibility Guidelines Working Group and 
others in the accessibility and standards community.

Please note, as well, the new section entitled "Document Formatting
Conventions" which explains the formatting conventions and mechanisms
used so as to provide as much information to the user so that an 
individual user can tweak his or her technology to designate semantic 
markers, such as "good examples" (green text on white background) 
and "bad examples" (red text on white background)

Note that a rather vague attempt at replacing CURIEs (upon which the 
XHTML Access Module had a dependency) with "named role values"; this
is a topic which needs to be discussed by the PFWG (support for CURIEs
now or in a future version, as was done with support for CURIEs in the 
ARIA suite).

http://lists.w3.org/Archives/Public/www-archive/2010May/att-0020/access-element-20100519.html

----------------------------------------------------------
He that will not apply new remedies must expect new evils; 
for time is the great innovator.      -- Sir Francis Bacon
----------------------------------------------------------
           Gregory J. Rosmaita: oedipus@hicom.net
       Camera Obscura: http://www.hicom.net/~oedipus/