W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2010

bug reports on accesskey (not reported to list)

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Mon, 27 Sep 2010 19:35:55 +0100
To: public-html-a11y@w3.org
Message-Id: <20100927183346.M17274@hicom.net>
aloha!

whilst w3c's public bugzilla is still accepting bugs, it is experiencing
an "internal server error" which i have reported to the pertinent 
authorities, along with the error generated whenever one commits a
new bug (basically, the email notification functions fail), so i am 
sending to public-html-a11y the bugs i have filed so far on accesskey 
in HTML5 -- note that i have used the string =-=-= (that's 
equals dash equals dash equals) to indicate the start of a new 
bug


PART 1: recently filed bugs which haven't hit public-html-a11y

Bug 10772 accesskey and an ordered set of unique space-separated tokens
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=10772

   Description From  Gregory J. Rosmaita   2010-09-27 17:40:43

in the definition of accesskey, HTML5 states:

QUOTE cite="http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute"
   All HTML elements may have the accesskey content attribute set. The 
   accesskey attribute's value is used by the user agent as a guide for 
   creating a keyboard shortcut that activates or focuses the element.

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

and yet, at:

http://dev.w3.org/html5/spec/common-microsyntaxes.html#ordered-set-of-unique-space-separated-tokens

HTML5 defines an ordered set of unique space-separated tokens as "a set 
of space-separated tokens where none of the words are duplicated but 
where the order of the tokens is meaningful."

this is an incomplete definition, as accesskeys are characters, not 
words.


PROPOSED CLARIFICATION:
   An ordered set of unique space-separated tokens is a set of 
   space-separated tokens where none of the characters or words are 
   duplicated, but where the order of the tokens is meaningful.


=-=-=

Bug 10773 accesskey should chosen from document's declared charset
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=10773

   Description From  Gregory J. Rosmaita   2010-09-27 17:46:29

CURRENT QUOTE
   If specified, the value must be an [161]ordered set of unique
   space-separated tokens, each of which must be exactly one Unicode code
   point in length.
UNQUOTE


PROBLEMS: "the value must be an ordered set of unique space-separated tokens"

1. a single character may be used for an accesskey assignment; the
spec should reflect this; 

2. although the spec uses the defined term "ordered set of unique
space-separated tokens" 


PROPOSED
An accesskey attribute's value may be a single character or an ordered 
set of unique space-separated tokens. Each character must be exactly 
one Unicode code point in length and must be part of the document's 
declared character set.



=-=-=

Bug 10774 fallback for accesskey insufficiently defined
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=10774

   Description From  Gregory J. Rosmaita   2010-09-27 17:48:28

current: 

QUOTE cite="http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute"
    1. If the element has no accesskey attribute [1], then skip to the
       fallback step below.
[snip]
    4. Fallback: Optionally, the user agent may assign a key combination
       of its choosing as the element's assigned access key [2] and then
       abort these steps.
UNQUOTE

[1] http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute
[2] http://dev.w3.org/html5/spec/editing.html#assigned-access-key


PROBLEM: 

1. combining steps one and four results in the following ambiguous 
rule:

"If no accesskey has been defined for the element, the user agent may 
assign a key combination of its choosing as the element's assigned access 
key and then abort the steps"

this is insufficient for the following reasons:

1.1. if the user agent assigns a key combination of its own as an 
element's assigned access key, the user agent MUST notify the user 
what accesskeys have been assigned to which elements;

1.2. if the user agent assigns a key combination of its own, such an 
assignment MUST not conflict with author-defined accesskeys; this means
that the author-defined access keys MUST be omitted from the collection
of user-agent assigned keys


REPLACE WITH:

  4. Fallback:

     A. if the user agent assigns a key combination of its own as 
        an element's assigned access key, 

            1. the user agent MUST notify the user what accesskeys 
               have been assigned to which elements;

            2. such an assignment MUST not conflict with 
               author-defined accesskeys; this means that the 
               author-defined access keys MUST be omitted from the 
               collection of keys available for the user-agent to 
               assign;

     B. Abort these steps


=-=-=

Bug 10775 how is user to decide which set of access keys to use?
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=10775

   Description From  Gregory J. Rosmaita   2010-09-27 17:55:39

QUOTE cite="http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute"
   If specified, the 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 1: how does the user know that more than one set of access keys
is available?

PROBLEM 2: how does the user select the set of access keys to use?

PROBLEM 3: can the use switch from one set of access keys to another
should the first set be too complicated to use?  if so, how?

PROBLEM 4: when using more than one token to assign an accesskey to 
a unique element, must all the accesskey values contain the same number 
of tokens in order for the accesskey values to validate?  

PROBLEM 5: why use the phrase "unique space-separated tokens"? 
"unique space-seperated characters, each of which must be exactly
one unicode point in length"


=-=-=

Bug 10776 accesskey value token subsets
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=10776

   Description From  Gregory J. Rosmaita   2010-09-27 17:57:17

For each value in keys in turn, in the order the tokens appeared in the 
attribute's value, run the following substeps

         1. If the value is not a string exactly one Unicode code point
            in length, then skip the remainder of these steps for this
            value.

         2. If the value does not correspond to a key on the system's
            keyboard, then skip the remainder of these steps for this
            value.

         3. If the user agent can find a combination of modifier keys
            that, with the key that corresponds to the value given in the
            attribute, can be used as a shortcut key, then the user agent
            may assign that combination of keys as the element's
            assigned access key and abort these steps.

PROBLEM with subsets 1 and 2: does this, in fact, mean:

         1. If the value is not a string exactly one Unicode code point
            in length, procede to the fallback step for this value.

         2. If the value does not correspond to a key on the system's
            keyboard, then procede to the fallback step for this value.

if so, why not say so?

subset 3 is event more problematic: for that i will submit a separate 
bug


=-=-=

Bug 10777 user agent assignment of modifier keys subset of accesskey
processing subset
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=10777


Description From Gregory J. Rosmaita 2010-09-27 17:59:19

as part of the substeps to run for each value in keys, in the order the 
tokens appeared in the attribute's value:

QUOTE
         3. If the user agent can find a combination of modifier keys
            that, with the key that corresponds to the value given in the
            attribute, can be used as a shortcut key, then the user agent
            may assign that combination of keys as the element's
            assigned access key and abort these steps.
UNQUOTE


what does this subset mean?  it should precisely address the following:

1. does this subset require a user agent to automatically determine 
a modifier or combination of modifier keys?

2. if so, is this so as to avoid conflicts with application and 
operating system hotkeys?

3. if the user agent automatically determines a modifier or combination
of modifier keys, how will this information be conveyed to the user

4. does the user retain control over which modifier key or combination
of modifier keys the user agent uses?

=-=-=

Bug 10778 use element.accessKeyLabel to generate list of available accesskeys
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=10778

   Description From  Gregory J. Rosmaita   2010-09-27 18:01:15

as part of the definition of Action the following is found:

QUOTE
element . accessKeyLabel
   Exposes the Access Key facet of the command.
UNQUOTE

the spec should explicitly state in

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

that user agents can use element.accessKeyLabel to generate list of 
available accesskeys


PROPOSED SPEC TEXT REVISION:

User agents may expose elements that have an accesskey attribute in 
other ways as well, e.g. in a menu displayed in response to a specific 
key combination. <ins>user agents can use 
<code>element.accessKeyLabel</code> to generate list of available 
accesskeys.</ins>

=-=-=

Bug 10779 triggering the Action of the command via accesskey
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=10779

   Description From  Gregory J. Rosmaita   2010-09-27 18:04:45

QUOTE cite="http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute"
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

note: the term "defines a command" is defined at:
http://dev.w3.org/html5/spec/commands.html#concept-command

this should be stated less obliquely:

When the user presses the key combination corresponding to the assigned 
access key for an element, if the element defines a command

    1. check if the command's Hidden state facet is false (visible)

    2. check if the command's Disabled state facet is false (enabled)

    3. if the command's Hidden and Disabled state facets are false, 
       trigger the Action of the command.


ADDITIONAL CONSIDERATION:

The above prose should be followed DIRECTLY by a note denoting that 
accesskey activation response MUST be controlled, storable and shareable 
by the user through a user agent setting. If an author defines a 
specific action to a command, users MUST be able to override the author's
suggested action, in observance of a persistent user setting. This 
allows the user to use a "safety" to avoid firing an event defined for
an element when the accesskey defined for that element is invoked, so
that a user may make an informed decision as to whether or not to 
activate the element or to move focus to that element in order to 
inspect it for pre-set triggers.

=-=-=

Bug 10780 reference to definition of Action insufficient for definition of
accesskey
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=10780

   Description From  Gregory J. Rosmaita   2010-09-27 18:06:38

QUOTE cite="http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute"
   When the user presses the key combination corresponding to the
   assigned access key [1] for an element, if the element defines a
   command [2], and the command's Hidden State facet [3] is false 
   (visible), and the command's Disabled State facet [4] is also 
   false (enabled), then the user agent must trigger the Action [5]
   of the command.

   User agents may expose elements that have an accesskey [6] attribute
   in other ways as well, e.g. in a menu displayed in response to a
   specific key combination.

   The accessKey IDL attribute must [7]reflect the [8]accesskey
   content attribute.
UNQUOTE

note: "reflect" is defined as:

QUOTE cite="http://dev.w3.org/html5/spec/common-dom-interfaces.html#reflect"
Some IDL attributes are defined to reflect a particular content 
attribute. This means that on getting, the IDL attribute returns the 
current value of the content attribute, and on setting, the IDL 
attribute changes the value of the content attribute to the given 
value.
UNQUOTE

note: "Action" is defined as: 

QUOTE cite="http://dev.w3.org/html5/spec/commands.html#command-facet-action"
    The actual effect that triggering the command will have. This 
    could be a scripted event handler, a URL to which to navigate, 
    or a form submission
UNQUOTE


PROBLEM: the user MUST be able to control whether the Action taken 
is to move focus to the element for which the accesskey has been 
defined or to activate that element.  this is a basic requirement in
order for accesskey to use for the class of users who use them 
primarily to navigate elements and those who use them primarily to 
activate elements; currently the HTML5 spec does not address this 
directly in its definition of the accesskey attribute, and the pointer
to the definition of "Action" as quoted above does not make it clear
that the Action that results from an accesskey+modifier keypress may
be to activate the element or to move focus to the element, in 
observance of user settings; if the user has not set a modifier key
to use to activate an accesskey, a user agent may assign one, 
provided that it notifies the user which modifier key or keys have
been assigned by the user agent.

References
1. http://dev.w3.org/html5/spec/editing.html#assigned-access-key
2. http://dev.w3.org/html5/spec/commands.html#concept-command
3. http://dev.w3.org/html5/spec/commands.html#command-facet-hiddenstate
4. http://dev.w3.org/html5/spec/commands.html#command-facet-disabledstate
5. http://dev.w3.org/html5/spec/commands.html#command-facet-action
6. http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute
7. http://dev.w3.org/html5/spec/common-dom-interfaces.html#reflect
8. http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute


=-=-=

Bug 10781 are accesskeys case sensitive?
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=10781

   Description From  Gregory J. Rosmaita   2010-09-27 18:07:56

1. the unicode expression of the latin capital letter x is U+0058

2. the unicode expression of the latin lowercase letter x is U+0078

so, since HTML5 states that, "If specified, the [accesskey] value must 
be an ordered set of unique space-separated tokens, each of which must 
be exactly one Unicode code point in length, does this mean that 
accesskeys are case sensitive?  if so, it must be explicitly stated;
if not, it also must be explicitly stated that accesskeys are case
insensitive.

=-=-=

Bug 10782 problems with button example for accesskey 
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=10782

   Description From  Gregory J. Rosmaita   2010-09-27 18:10:03

QUOTE
In the following example, a button has possible access keys described. 
A script then tries to update the button's label to advertise the key 
combination the user agent selected.

<input type=submit accesskey="N @ 1" value="Compose">
...
<script>
 function labelButton(button) {
   if (button.accessKeyLabel)
     button.value += ' (' + button.accessKeyLabel + ')';
 }
 var inputs = document.getElementsByTagName('input');
 for (var i = 0; i < inputs.length; i += 1) {
   if (inputs[i].type == "submit")
     labelButton(inputs[i]);
 }
</script>

On one user agent, the button's label might become "Compose (&#8984;N)". On 
another, it might become "Compose (Alt+&#8679;+1)". If the user agent doesn't 
assign a key, it will be just "Compose". The exact string depends on 
what the assigned access key is, and on how the user agent represents 
that key combination.
UNQUOTE


PROBLEM 1: The user should be the ultimate arbiter of which accesskey
to apply, not the user agent

    The exact string depends on which of the suggested access key sets 
    is in use, and upon how the user agent represents the key 
    combinations that comprise that set of accesskeys.


PROBLEM 2: there are characters used in the last paragraph that are
not exposed when using a screen reader -- in particular: 

   "<samp>Compose (&#8984;N)</samp>". On another, it might become
   "<samp>Compose (Alt+&#8679;+1)</samp>"

since the use of special characters constitutes ascii art, the 
character entities should be glossed using ABBR as follows:

   "<samp>Compose (<abbr title="Command-Key">&#8984;</abbr>N)</samp>"
   "<samp>Compose (Alt+<abbr title="UpArrow">&#8679;</abbr>+1)</samp>"

such extended characters should NOT be used in UA notifications, as the
values expressed using symbolic characters will not be read by a 
screen reader -- it is better for the UA to report "CommandKey+N"
and "ALT + UpArrow + 1"


PROBLEM 3: currently, the draft states: "If the user agent doesn't 
assign a key, it will be just "Compose". The exact string depends on 
what the assigned access key is, and on how the user agent represents 
that key combination."

PROPOSED:
If a user has set their user agent to use a specific key or key 
combination as accesskey modifiers, or if no modifier key has been 
pre-set as a default by the user agent, the user agent must not 
assign a specifc key, but simply report "Compose". The exact string 
depends on what the assigned access key is, and on how the user agent 
represents that key combination.


PROBLEM 4: how does the user notify the script which set of access 
keys that user wishes to use?

=-=-=

PART 2: bugs on accesskey logged earlier:

Bug 10251 Psuedo-Cascade of Multiple Accesskeys Definable for an 
Individual Element
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=10251
* hixie marked RESOLVED, but a11y-tf is tracking this bug
* QUESTION: should i split this report into 2 and re-submit (seems to 
be what hixie wants)

=-=-=

Bug 10252: HTML5 hard-binds "Action" to accesskey key-press 
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=10252
* status: RESOLVED NEEDSINFO
* hixie notes:  Did Not Understand Request
* should i try and slice this into new bugs?
Received on Monday, 27 September 2010 18:36:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:14 UTC