[Access Module LC] Review Comments (PR#8043)

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 19:26:45 UTC