Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This note outlines the way in which the XHTML 2 Working Group has addressed comments received during the last call period against the Last Call Working Draft of XHTML Access.
During the last call period for XHTML Access the working group received a few comments. This document summarizes those comments and describes the ways in which the comments were addressed by the XHTML 2 Working Group.
Note that the majority of this document is automatically generated from the Working Group's database of comments. As such, it may contain typographical or stylistic errors. If so, these are contained in the original submissions, and the XHTML 2 Working Group elected to not change these submissions.
This document is a Note of the W3C's XHTML 2 Working Group. This Note may be updated, replaced or rendered obsolete by other W3C documents at any time. It is inappropriate to use W3C Notes as reference material or to cite them as other than "work in progress". This document is work in progress and does not imply endorsement by the W3C membership.
This document has been produced by the W3C XHTML 2 Working Group as part of the HTML Activity. The goals of the XHTML 2 Working Group are discussed in the XHTML 2 Working Group charter.
This document is governed by the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Please send detailed comments on this document to www-html-editor@w3.org. We cannot guarantee a personal response, but we will try when it is appropriate. Public discussion on HTML features takes place on the mailing list www-html@w3.org.
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.
| Issue | Working Group Action | Commentor Position | Change Type | Notes |
|---|---|---|---|---|
| 8043: [Access Module LC] Review Comments | Modify and Accept | None | Editorial | Accepted most comments, with minor editorial changes. |
| 8045: [XHTMLAccess] i18n comment 3: Reference to accesskey | Accept | None | N/A | Added a note about how this module is the successor to accesskey. |
| 8046: [XHTMLAccess] i18n comment 1: Use of terms key and access key | Accept | None | Editorial | We added lots of text to clarify what we mean by "key". |
| 8048: [XHTMLAccess] i18n comment 5: Examples and explanations | Accept | None | Editorial | We added a few more examples, and also tightened up this wording. |
| 8054: LC comment on access module usage with XForms | Reject | None | None | The group feels this situation is already handled as extensively as it can be in this document. |
| 8047: [XHTMLAccess] i18n comment 2: Keycode or character | Modify and Accept | None | Editorial | We tried to address this by making certain that people understand that "key" is an abstraction and does not correlate to a "key code". |
| 8044: [XHTMLAccess] i18n comment 4: Rendering by user agent | Accept | None | None | The working group feels the current wording addresses this case already. Steven will respond formally. |
PROBLEM ID: 8043
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: None
NOTES:
Accepted most comments, with minor editorial changes.
ORIGINAL MESSAGE:
Date: Sun, 22 Jun 2008 05:49:26 -0400
From: Doug Schepers <schepers@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
REPLY 1:
From: Shane McCarron <xhtml2-issues@mn.aptest.com> Date: Sat Oct 18 17:45:19 2008 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 > >
PROBLEM ID: 8045
STATE: Approved and Implemented
EDIT: N/A
RESOLUTION: Accept
USER POSITION: None
NOTES:
Added a note about how this module is the successor to accesskey.
ORIGINAL MESSAGE:
Date: Wed, 06 Aug 2008 08:12:42 +0100 From: ishida@w3.org Comment from the i18n review of: http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080526/ Comment 3 At http://www.w3.org/International/reviews/0806-xhtml-access/Overview.html Editorial/substantive: E Tracked by: RI Location in reviewed document: 3.1.2 [http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080526/#sec_3.1.2.] Comment: We were surprised to find no reference to the existing accesskey markup, and its relationship to the markup described here.
PROBLEM ID: 8046
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: None
NOTES:
We added lots of text to clarify what we mean by "key".
ORIGINAL MESSAGE:
Date: Wed, 06 Aug 2008 08:12:15 +0100 From: ishida@w3.org Comment from the i18n review of: http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080526/ Comment 1 At http://www.w3.org/International/reviews/0806-xhtml-access/Overview.html Editorial/substantive: E Tracked by: RI Location in reviewed document: 3.1.2 [http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080526/#sec_3.1.2.] Comment: The term 'access key' seems to be used to refer to the value of the key attribute in one part of this section, and to a key on a physical keyboard in other places. The word 'key' is also used in ways that are not clearly tied down, especially in light of the above. Please clearly define what is meant when these terms are used and use them consistently.
PROBLEM ID: 8048
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: None
NOTES:
We added a few more examples, and also tightened up this wording.
ORIGINAL MESSAGE:
Date: Wed, 06 Aug 2008 08:13:52 +0100 From: ishida@w3.org Comment from the i18n review of: http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080526/ Comment 5 At http://www.w3.org/International/reviews/0806-xhtml-access/Overview.html Editorial/substantive: E Tracked by: RI Location in reviewed document: General Comment: Phrasing such as 'assigning an accessibility mapping' or 'the document focus or an inspection focus' are not very clear, and there is no clarification or links to definitions. A few more examples, and explanations of how they affect the user experience (not just code snippets), would also be welcome.
PROBLEM ID: 8054
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Reject
USER POSITION: None
NOTES:
The group feels this situation is already handled as extensively as it can be in this document.
ORIGINAL MESSAGE:
From: John Boyer <boyerj@ca.ibm.com> Date: Mon, 6 Oct 2008 22:49:15 -0700 This is a multipart message in MIME format. --=_alternative 001FF960882574DB_= Content-Type: text/plain; charset="US-ASCII" The Forms WG discussed the issue below at its last face to face meeting, and I see now that the action item to send this note to XHTML2 "fell off the side of my desk" so to speak. The issue is how to handle the access element in the context of documents with a run-time execution model that includes some sort of dynamic content generation. The main example that came to mind was the XForms repeat, which iterates its content once for each node of data associated with the repeat by the run-time execution model. The template content may contain elements with IDs. Such languages define (or should define) rules for how to handle IDREFs to repeated elements with IDs. At a minimum, a note about the existence of such markup languages seems warranted, along with advice to suggest that IDREF resolution is done according to that language. To ensure you fully consider whether you want to go with this suggestion please note that the IDREF resolution method in XForms has two properties to consider: 1) Suppose you have an access element in a document, suppose you have a repeat element as its following sibling, and suppose the targetid of the access element indicates an element within the repeat. Since the access element is outside of the repeat, the XForms IDREF method would provide the run-time element that matched both the requested ID and the current index of the repeat. 2) Suppose you have an access element *inside* of a repeat whose targetid indicates an element within the same repeat. The repeat will iterate the access element in each "repeat item". The XForms IDREF method in this case would resolve to the same repeat item whether or not the repeat item is the one currently indexed. Is it appropriate for the access element to be scoped to operating within the containing repeat item? Cheers, John M. Boyer, Ph.D. STSM, Interactive Documents and Web 2.0 Applications Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw --=_alternative 001FF960882574DB_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">The Forms WG discussed the issue below at its last face to face meeting, and I see now that the action item to send this note to XHTML2 "fell off the side of my desk" so to speak.</font> <br> <br><font size=2 face="sans-serif">The issue is how to handle the access element in the context of documents with a run-time execution model that includes some sort of dynamic content generation.</font> <br> <br><font size=2 face="sans-serif">The main example that came to mind was the XForms repeat, which iterates its content once for each node of data associated with the repeat by the run-time execution model.</font> <br> <br><font size=2 face="sans-serif">The template content may contain elements with IDs. Such languages define (or should define) rules for how to handle IDREFs to repeated elements with IDs. At a minimum, a note about the existence of such markup languages seems warranted, along with advice to suggest that IDREF resolution is done according to that language.</font> <br> <br><font size=2 face="sans-serif">To ensure you fully consider whether you want to go with this suggestion please note that the IDREF resolution method in XForms has two properties to consider:</font> <br> <br><font size=2 face="sans-serif">1) Suppose you have an access element in a document, suppose you have a repeat element as its following sibling, and suppose the targetid of the access element indicates an element within the repeat. Since the access element is outside of the repeat, the XForms IDREF method would provide the run-time element that matched both the requested ID and the current index of the repeat.</font> <br> <br><font size=2 face="sans-serif">2) Suppose you have an access element *inside* of a repeat whose targetid indicates an element within the same repeat. The repeat will iterate the access element in each "repeat item". The XForms IDREF method in this case would resolve to the same repeat item whether or not the repeat item is the one currently indexed. Is it appropriate for the access element to be scoped to operating within the containing repeat item?</font> <br> <br><font size=2 face="sans-serif">Cheers,</font> <br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br> STSM, Interactive Documents and Web 2.0 Applications<br> Chair, W3C Forms Working Group<br> Workplace, Portal and Collaboration Software<br> IBM Victoria Software Lab<br> E-Mail: boyerj@ca.ibm.com <br> <br> Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/page/JohnBoyer</font></a><font size=2 face="sans-serif"><br> Blog RSS feed: </font><a href="http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw"><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw</font></a><font size=2 face="sans-serif"><br> <br> </font> --=_alternative 001FF960882574DB_=--
REPLY 1:
From: Shane McCarron <xhtml2-issues@mn.aptest.com> Date: Sat Oct 18 16:16:35 2008 John, This is a formal response to the XForms last call comments on the XHTML Access Module. Please reply and indicate whether you accept the proposed resolution. In general the working group feels that the issue of multiple elements having the same XML ID is outside of the scope of this module. In the vast majority of cases this situation will never arise, since such a document would be invalid. We understand that in the context of XForms and its repeat element, it is possible for multiple elements to have the same XML ID, since only one of those elements is "active" at a time. The working group feels that there is language in XHTML Access already to handle the situation where a document changes (e.g., when an XML ID moves from one element to another). Specifically: "The location of the next matching element MUST be determined each time the access element is triggered, since it is possible that between events the contents of the document will have changed." If XForms needs to impose additional constraints or provide additional advice to authors and implementors, we believe it should be done in the context of the XForms specification rather than the XHTML Access module. We believe this is similar to how XForms has dealt with CSS-related issues in the past. Thanks in advance for your understanding of this decision. Shane McCarron (on behalf of the XHTML 2 Working Group) > The issue is how to handle the access element in the context of documents > with a run-time execution model that includes some sort of dynamic content > generation. > > The main example that came to mind was the XForms repeat, which iterates > its content once for each node of data associated with the repeat by the > run-time execution model. > > The template content may contain elements with IDs. Such languages define > (or should define) rules for how to handle IDREFs to repeated elements > with IDs. At a minimum, a note about the existence of such markup > languages seems warranted, along with advice to suggest that IDREF > resolution is done according to that language. > > To ensure you fully consider whether you want to go with this suggestion > please note that the IDREF resolution method in XForms has two properties > to consider: > > 1) Suppose you have an access element in a document, suppose you have a > repeat element as its following sibling, and suppose the targetid of the > access element indicates an element within the repeat. Since the access > element is outside of the repeat, the XForms IDREF method would provide > the run-time element that matched both the requested ID and the current > index of the repeat. > > 2) Suppose you have an access element *inside* of a repeat whose targetid > indicates an element within the same repeat. The repeat will iterate the > access element in each "repeat item". The XForms IDREF method in this > case would resolve to the same repeat item whether or not the repeat item > is the one currently indexed. Is it appropriate for the access element to > be scoped to operating within the containing repeat item?
PROBLEM ID: 8047
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: None
NOTES:
We tried to address this by making certain that people understand that "key" is an abstraction and does not correlate to a "key code".
ORIGINAL MESSAGE:
Date: Wed, 06 Aug 2008 08:12:28 +0100 From: ishida@w3.org Comment from the i18n review of: http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080526/ Comment 2 At http://www.w3.org/International/reviews/0806-xhtml-access/Overview.html Editorial/substantive: S Tracked by: RI Location in reviewed document: 3.1.2 [http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080526/#sec_3.1.2.] Comment: It isn't clear that this section has taken into account the potential difference between key codes and the characters that may result from a key press on a given keyboard. It seems to assume that the character on a key cap == the key code identifier == the character produced by pressing that key == the character that is the value of the key attribute. This is not always the case when you take into account a variety of keyboards serving various different locales. Please provide some precision as to how a key attribute value is associated with keyboard events. (Note that this has proved to be a difficult topic for the specification of DOM3 keyboard events.)
PROBLEM ID: 8044
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Accept
USER POSITION: None
NOTES:
The working group feels the current wording addresses this case already. Steven will respond formally.
ORIGINAL MESSAGE:
Date: Wed, 06 Aug 2008 08:13:27 +0100 From: ishida@w3.org Comment from the i18n review of: http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080526/ Comment 4 At http://www.w3.org/International/reviews/0806-xhtml-access/Overview.html Editorial/substantive: S Tracked by: RI Location in reviewed document: 3.1.2 [http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080526/#sec_3.1.2.] Comment: "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 is likely to be problematic for non-Western text. For example, in scripts that combine character into complex shapes (such as Hindi/Devanagari or Urdu/Nastaliq) it can be difficult to isolate a specific character. For such scripts it is likely to be better to give the control to the author when identifying the character to highlight. In some cases the author may include the access key in parentheses after the label, in others they may prefer to highlight a letter in the label itself.