- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Mon, 27 Sep 2010 19:35:55 +0100
- To: public-html-a11y@w3.org
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 (⌘N)". On
another, it might become "Compose (Alt+⇧+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 (⌘N)</samp>". On another, it might become
"<samp>Compose (Alt+⇧+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">⌘</abbr>N)</samp>"
"<samp>Compose (Alt+<abbr title="UpArrow">⇧</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