W3C

XHTML Access Last Call Disposition of Comments

18 October 2008

This version:
http://www.w3.org/MarkUp/2008/xhtml-access-lc-doc-20081018.html
Latest version:
http://www.w3.org/MarkUp/xhtml-access-lc-doc.html
Editors:
Shane McCarron, Applied Testing and Technology, Inc.

Abstract

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.

Status of this document

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.

Table of Contents

IssueWorking Group ActionCommentor PositionChange TypeNotes
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.

1. Access

1.1 [Access Module LC] Review Comments

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
  > 
  > 

1.2 [XHTMLAccess] i18n comment 3: Reference to accesskey

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. 
  
   
  

1.3 [XHTMLAccess] i18n comment 1: Use of terms key and access key

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. 
  
   
  

1.4 [XHTMLAccess] i18n comment 5: Examples and explanations

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.
  
   
  

1.5 LC comment on access module usage with XForms

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 &quot;fell off the side of my desk&quot; 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. &nbsp;Such languages define (or should define) rules for how
  to handle IDREFs to repeated elements with IDs. &nbsp;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. &nbsp;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. &nbsp;The repeat will iterate the access element in each &quot;repeat
  item&quot;. &nbsp;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. &nbsp;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 &nbsp;<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?

1.6 [XHTMLAccess] i18n comment 2: Keycode or character

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.) 
  
   
  

1.7 [XHTMLAccess] i18n comment 4: Rendering by user agent

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.