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

Should these issues be raised as Bugzilla bugs on the HTML5 spec?

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of Gregory J. Rosmaita
Sent: Thursday, July 22, 2010 9:35 AM
To: public-html-a11y@w3.org
Subject: 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/