- From: Doug Schepers <schepers@w3.org>
- Date: Sun, 22 Jun 2008 05:49:26 -0400
- To: www-html-editor@w3.org
Hi, XHTML2 WG-
Here is my personal review of the XHTML Access Module. The SVG WG may
have more to say later. I believe that this spec would be a good fit
for inclusion in the planned SVG accessibility module that includes the
'role' attribute and ARIA extensions. [1]
I do think it needs a little tightening up for implementors to achieve
interop, and needs more explanatory prose for potential authors and
users. I also note that you don't have any conformance criteria for
authoring tools, just browsers; I wonder if there is some way to include
best practices, perhaps in conjunction with XHTML Vocabulary namespace.
3. XHTML Access Module
"This module defines the access element."
That's a bit terse. Please provide an explicit informative overview of
the what the purpose and mechanism for the access element is.
Everything is extremely vague up to section 3.1., and it doesn't become
clear until one has read the entire spec.
I think it would be helpful to preface the document with wording to the
effect of:
"Most desktop applications provide a way for the user to navigate or
activate specific functionality through the use of the keyboard alone,
particularly by using keyboard shortcuts, which are a single key or
combination of keys. Web pages and Web Applications have traditionally
been less able to do so due to conflicting shortcuts within the
operating system or browser itself, and due also to a lack of a coherent
robust mechanism. Thus, Web resources have relied primarily on
interaction via pointing devices, such as a mouse. This specification
defines a way to assign character mappings (e.g. keyboard shortcuts, or
keys combinations) to navigate to specific elements or sequential sets
of elements, which may be activated by the user, or which may be
activated immediately, based on the author's intent. It also addresses
the need for end users to be able to remap these keys for personalizing
the interaction, and describes how a browser might expose these
character mappings to the user."
3.1. The access element
"The access element assigns an accessibility mapping to elements within
a document."
Mapping *what* to elements within the document? It seems that the only
thing it can map is keyboard shortcuts... is that the case? If so, say
that. If not, what else can it bind to besides keys?
"Actuating the mapping results in the element gaining focus (either the
document focus or an inspection focus, as determined by the user agent),
and, if set by the author and permitted by the user's settings, in one
or more other events being activated."
This wording is a little convoluted, and it buries the lead.
I also don't know the difference between "document focus", "inspection
focus", and "content focus", and others may not either, so it's worth
defining them, or linking to the definition if it already exists. How
do these terms correspond to focus, content focus, user interface focus,
and current focus, as defined in UAAG 1.0 [2]?
What happens if an element matches one of the @targetid or @targetrole
values, but the element is disabled or otherwise unable to receive
focus? Does it get skipped? Should the host language specify this? If
so, say so.
"If neither a targetrole nor a targetid attribute are specified, the
user agent MUST NOT define a mapping nor deliver any events."
What does it mean to deliver events? Is that the same as dispatching
events? If so, please use the word dispatch. If not, please define or
link to a definition for event delivery.
Can the <access> element obtain focus? If so, what would that mean, and
would it be useful? What would happen if an <access> element shifted
focus, directly or indirectly, to itself, and its 'activate' attribute
value were "yes"... would that result in an infinite loop? (Like,
trippy, man...)
A clearer way of wording this section might be something like:
[[
The <access> element allows an author to specify a relationship between
a particular key and one or more elements within a document. When that
key event is triggered, one of the specified target elements gains
focus, and one or more other events (such as an 'activate' event) may
also be dispatched to that element. The target elements are specified
by means of the 'targetid'[link] or 'targetrole'[link] attributes, and
these elements may each contain multiple targets, to allow sequential
focus by successively activating the same key.
The focus may be a document focus [link to def], or an inspection focus
[link to def], as determined by the user agent. If an target element is
disabled, or otherwise unable to receive focus, then it must be ignored,
and will not receive focus.
If the <access> element's 'activate'[link] attribute has the value
'yes', then in addition to receiving focus, the target element will be
activated, if permitted by the user's settings. Additionally, using XML
Events [link], one or more other events may also be dispatched to the
element, in the following manner: (brief overview).
An access element must have either a 'targetrole'[link] or a
'targetid'[link] attribute specified. If neither a 'targetrole'[link]
nor a 'targetid'[link] attribute are specified, or if there are no
matching elements in the document, the user agent MUST NOT define a
mapping for this element, nor change focus nor dispatch any events based
on this element.
]]
3.1.1. activate = ( yes | no* )
"activate = ( yes | no* )"
Shouldn't that be "activate = ( activate | noactivate* )" or something?
I wonder if there's ever likely to be another value? If not, ignore
this comment. (FWIW, I would prefer "true|false".)
3.1.2. key = Character
"An access key is a single character from the document character set."
A key is not a character... an author could usefully define a
non-character key to be a hotkey. I strongly recommend that you use
DOM3 Events key identifiers [3] as the value, as this is a clear case of
what key identifiers are being defined for.
Naturally, this has implications for how the key in question would be
revealed to the user if it is not a character key that is in the label
of a target element, but since this is not normatively defined behavior
anyway (it seems), then the UA could choose another way to expose the
info (and if the 'key' value does happen to be a character, then of
course it can show any matching characters).
What happens if two different <access> elements use the same 'key'
attribute value? Which takes precedence? Is one ignored, or can they
be "stacked"?
"Triggering the access key defined in an access element moves focus from
its current position to the next element in navigation order that has
one of the referenced role or id values (see activate for information on
how the element may be activated)."
It's not clear from this sentence that the targetid and targetrole
contain lists, and I recommend that you clarify this earlier on, as in
my suggested text.
"Note that it is possible to deliver alternate events via [XMLEVENTS]."
Sounds cool, but what does it mean? Please provide a prose example of
what this means, and how it would work in practice. Show, don't tell.
"The invocation of access keys depends on the implementation. For
instance, on some systems one may have to press an "alt" or "cmd" key in
addition to the access key."
Hmmm... I understand the dilemma here... still it might be better for
interop if you took a stand, even if it's just a SHOULD or MAY. I'm
curious what the desktop and mobile browser vendors would say here?
"User agents MUST provide mechanisms for overriding the author setting
with user-specified settings ... "
I like this, but I don't think it's quite baked. Have you gotten input
from the browser vendors how this should be handled? I don't object to
this at all, I'd just like to see it more defined if possible.
"If no key attribute is specified, the user agent SHOULD assign a key
and alert the user to the key mapping. The resultant user agent assigned
key mapping SHOULD persist."
Persist per page, per domain, per cookie, per CURIE value, or what?
"The rendering of access keys depends on the user agent. We recommend
that authors include the access key character in label text or wherever
the access key is to apply. If the user agent can recognize that the
currently mapped access key character appears in the label text of the
element to which it is mapped, then the user agent may render the
character in such a way as to emphasize its role as the access key and
distinguish it from other characters (e.g., by underlining it)."
This was a bit thick, and I had to read it a couple times before I got
it. You might preface it with something like, "It is common for UAs to
provide a visual hint for accessing features via keyboard shortcuts,
such as showing the shortcut next to a menu item, or underlining the
shortcut character letter in a label."
It would be interesting to see what the CSS WG thinks about this... an
author might be able to use the CSS 'content' property to add the
styling hint to the label.
(Note that SVG doesn't have labels per se, but with ARIA a <text>
element might be assigned the role of label, so in our module we should
mention that.)
"A conforming user agent SHOULD also provide a centralized view of the
current access key assignments (see Checkpoint 11.1 and Checkpoint 11.2
of UAAG 1.0)."
Again, cool, but I'd be curious how the browser vendors think this might
be done, and I wonder if a best practice could be included.
3.1.3. targetid = IDREFs
"The targetid attribute specifies one or more IDREFs related to target
elements for the associated event (i.e., the node to which the event
should be delivered)."
You need to define the content model, i.e. "The 'targetid' attribute
specifies a space separated list of one or more IDREFs..."
3.1.4. targetrole = CURIEs
"If a targetid and a targetrole are both specified for an element, the
targetid attribute value must take precedence."
It's not clear what "take precedence" means. What if there is both a
targetid and a targetrole, each with multiple entries? Once the user
leaves the last match, in document order, that is listed in the
targetid, but there is a later document-order element that matches a
value in the targetrole list, what happens? Does the focus skip back to
the first document-order element that matches the targetid list, or pick
up on any matches in the targetrole list?
What if there is a targetid with a blank attribute value, or with no
values that have matching elements, but a targetrole with one or more
value with matching elements?
"If the prefix is omitted from a CURIE, the default value of
http://www.w3.org/1999/xhtml/vocab# MUST be used."
Please briefly explain in the spec what the significance of that
particular namespace is. It seems that there are a lot of semantic bits
being floated around, from XHTML Vocabulary namespace to ARIA... it
would be nice to have a concerted effort to avoid confusion for authors.
Examples
Please give the examples their own heading... the current document
structure suggests that they are examples specific to section 3.1.4. (at
least "Access element that goes to a specific element" is not).
Further, give each example an label and id, so that can be linked to.
Please provide more examples for use, especially ones that contain
multiple values in @targetid and @targetrole, and explain how they
should work. (You could reuse these for the test suite.)
[UAAG1]
"User Agent Accessibility Guidelines 1.0". Ian Jacobs et al., 17
December 2002.
The link here is wrong, it leads to XHTML 2.0.
[1] http://lists.w3.org/Archives/Public/www-svg/2008Jun/0040.html
[2] http://www.w3.org/TR/UAAG10/glossary.html#def-content-focus
[3] http://www.w3.org/TR/DOM-Level-3-Events/keyset.html#KeySet-Set
Regards-
-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF
Received on Sunday, 22 June 2008 09:50:01 UTC