- From: Shane McCarron <xhtml2-issues@mn.aptest.com>
- Date: Sat, 18 Oct 2008 12:45:18 -0500
- To: schepers@w3.org
- CC: www-html-editor@w3.org
Doug, According to our records we did not formally reply to your last call comments - which surprises me, since I was *certain* that we had. Please consider this document a formal reply and please respond indicating whether you accept the resolution(s) of the working group. Our comments are embedded below. You can see the latest draft via http://www.w3.org/Markup/Drafts#xhtml-access Shane McCarron (on behalf of the XHTML 2 Working Group) > > 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." We have incorporated this into the Introduction - thanks! > 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? > Yes, in conjunction with XML Events or other intrinsic events you could map other things. We have changed the wording so it is still vague, but perhaps less so. > "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]? We have rephrased this so it does not use these terms - they are not critical to understanding at this point and, as you pointed out, could confuse the reader. > 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. We have added a constraint that the host language MUST define under what circumstances an element would not be a "matching element" - we believe such a constraint will address this concern. Thanks for pointing this out! > > > "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. We meant "dispatch" - thanks. > 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...) We think it is up to the host language as to whether the access element could obtain focus. However, in the default case, since the content model of the access element is "EMPTY" there would be nothing upon which to focus. Also, in the default case, the access element is only permitted within the "head" element, which in XHTML languages cannot receive focus either. So we think this is an unlikely risk. > > > 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. > ]] Your suggested changes were great! However, we needed to merge your ideas with some others. We think the resulting text is almost as good, and hopefully addresses everyone's concerns. > 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".) We changed this to "true" | "false" - thanks. > 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). Actually, we said this on purpose. "key" is a convenience feature, and allows authors to simply indicate mappings. In conjunction with XML Events 2 and DOM 3 Events you could define more rigorous restrictions. > > What happens if two different <access> elements use the same 'key' > attribute value? Which takes precedence? Is one ignored, or can they > be "stacked"? the specification indicates that this is not legal (Authors MUST NOT). We have extended this to clarify that in the face of such usage, the behavior is unspecified. > > > "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 meaning of this is nebulous on purpose, since XMLEVENTS are not required for the use of XHTML Access Module. It is outside the scope of the module to define how XML Events or other event models work. For example, were this module used in conjunction with XHTML 1.1 and the XHTML Intrinsic Events module, I would expect that some of those event attributes could be bound to an access element. It is up to the host language to define that interaction. > "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? We have added a bunch of text about how this is an abstraction - we feel the new text at least helps to understand how a "key" gets interpreted. > "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. This is as specific as we can get right now. And no, there has been no input from browser vendors on this requirement up til now. > "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? Across sessions - we added that text. Thanks! > "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." Good idea - thanks! > > > "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. Much of this language was provided by the WAI folks, and we assume they crafted it in conjunction with the user agent developers. However, no specific feedback from them has been sent to the XHTML 2 Working Group. > 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..." Good catch! > 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? We changed the constraint - what we meant was that the user agent must ONLY use the targetid attribute values. > "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. We added a sentence and a reference to the Vocab document, so as to not duplicate the content at that URI. > > 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. Will do! > > 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.) We will put in some additional examples. > > [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. Good catch - thanks! > > > > [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 Saturday, 18 October 2008 17:46:56 UTC