re: [Access Module] rewrites accepted save for 1 question

Hello,
See message below. The UAWG appreciates the adoption of the proposed wording
changes to the ACCESS Module for XHTML2.  We have received your concerns.
UAWG is having a conference call today and will address the 2 issues (Should
vs Must, and definition of 'session') at the top of the agenda. UAWG will
hopefully have responses to these issues today. 

Minutes from the telecons focused on Access Module Discussion on May 8
http://www.w3.org/2008/05/08-ua-minutes.html 
And May 13 http://www.w3.org/2008/05/13-ua-minutes.html 

Jim Allan, Co-Chair UAWG

-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org] On Behalf
Of Jim Allan
Sent: Wednesday, May 14, 2008 4:10 PM
To: 'Gregory J. Rosmaita'; w3c-wai-ua@w3.org
Cc: wai-liaison@w3.org
Subject: RE: [Access Module] rewrites accepted save for 1 question


Gregory,
This needs a bit of discussion with the group. We have a call tomorrow and I
will add it to the agenda. UAAG10 was release in 2002 and used Priority
Level to determine importance. Additionally, the wording of the normative
checkpoints is not precise in their intent. The referenced checkpoints (9.5,
9.6, and 11.3) are all Priority Level 2. As such the group agreed on an RFC
2119 SHOULD to align with our interpretation/mapping of Priority Levels to
RFC 2119. 
That said, given the strong feelings of the XHTML2 working group further
review is necessary.

Additionally, defining 'session' will also be addressed during the call.

Jim   

> -----Original Message-----
> From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org] On
> Behalf Of Gregory J. Rosmaita
> Sent: Wednesday, May 14, 2008 1:43 PM
> To: w3c-wai-ua@w3.org
> Cc: wai-liaison@w3.org
> Subject: [Access Module] rewrites accepted save for 1 question
> 
> 
> aloha!
> 
> the XHTML2 working group received our proposed re-wording for the
> Access Module very warmly, and decided to incorporate it into what
> will transition to the final Last Call draft for the Access Module,
> with the following amendments:
> 
> [note: the paragraph and sentence pointers refer to the contents
> of this post -- in the interest of getting timely feedback on the
> small lingering issue, i decided to post this and THEN edit the
> pertinent UAWG wiki pages]
> 
> point 1. Section 3.1.1. Paragraph 1, Sentence 3:
> 
> <QUOTE>
> User agents <del>SHOULD</del> <ins>MUST</ins> provide mechanisms for
> overriding the author setting with user-specified settings in order to
> ensure that the act of moving content focus does not cause the user
> agent to take any further action, as required by UAAG 1.0, Checkpoint
> 9.5. [1]
> </QUOTE>
> 
> the XHTML2 WG felt very strongly that this "should" must be an RFC
> 2119 "MUST" - http://www.rfc-editor.org/rfc/rfc2119.txt; furthermore
> the XHTML2 WG requested that it be repeated in section 3.1.2.
> (Parenthetically, the XHTML2 WG was surprised that the UAWG came down
> on the side of "should" in section 3.1.2. wherever there had been a
> discussion over the normative terms "SHOULD" and "MUST")
> 
> 
> point 2. there is no defined encapsulation of the concept of "sessions"
> as articulated in the re-wording for Section 3.1.2, Paragraph 4,
> Sentence 6
> 
> <QUOTE>
> If a user chooses to change the key binding, the resultant user-defined
> remapping SHOULD persist across sessions.
> </QUOTE>
> 
> the XHTML2 WG asked the UA WG to either provide a reference for
> the term "sessions" or a definition of the term.
> 
> thanks again to everyone who has put aside other burning issues to
> address the Access Module issues -- with the Access Module and
> XHTML Role Module moving toward REC status, access keying and ARIA
> will provide a firm foundation for the enhanced accessibility
> envisioned by the ARIA Roadmap, which means measurable progress,
> which is always a good thing...
> 
> gregory.
> 
> --- BEGIN FINAL(?) PROPOSED RE-WORDING ---
> 
> 3.1. The access element
> [http://www.w3.org/WAI/UA/wiki/AccessModule/AccessElement]
> 
> The access element assigns an accessibility mapping to elements within
> a document. 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.
> 
> An access element must have either a targetrole or a targetid attribute
> specified. If neither a targetrole nor a targetid attribute are
> specified, the user agent MUST NOT define a mapping nor deliver any
> events.
> 
> 
> 3.1.1. activate = ( yes | no* )
> [http://www.w3.org/WAI/UA/wiki/AccessModule/ActivateAttribute]
> 
> The activate attribute indicates whether a target element should be
> activated or not once it obtains focus. The default value for this
> attribute is "no", indicating that the element will not be "activated".
> User agents <del>SHOULD</del> <ins>MUST</ins> provide mechanisms for
> overriding the author setting with user-specified settings in order to
> ensure that the act of moving content focus does not cause the user
> agent to take any further action, as required by UAAG 1.0, Checkpoint
> 9.5. [1]
> 
> User agents MUST provide keyboard mechanisms for "activating" any event
> associated with the focused element (UAAG 1.0, Checkpoint 1.2) [2] and
> SHOULD make available the list of events associated with the element
> (UAAG 1.0, Checkpoint 9.6). [3]
> 
> 
> 3.1.2. key = Character
> [http://www.w3.org/WAI/UA/wiki/AccessModule/KeyMappingBinding]
> [also: http://www.w3.org/WAI/UA/wiki/KeyMappingBinding/Talk]
> 
> This attribute assigns a key mapping to an access shortcut. An access key
> is a single character from the document character set.
> 
> 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 (consult Section 3.1.1, Activate for
> information on how the element may be activated). Note that it is
> possible to deliver alternate events via XMLEVENTS.
> 
> 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.
> 
> User agents MUST provide mechanisms for overriding the author setting
> with user-specified settings in order to ensure that the act of moving
> content focus does not cause the user agent to take any further action,
> as required by UAAG 1.0, Checkpoint 9.5. [1] The character assigned to
> a key, and its relationship to a role or id attribute SHOULD be treated
> as an author suggestion. User agents may override any key assignment
> (e.g., if an assignment interferes with the operation of the user
> interface of the user agent, if the key is not available on a device,
> if a key is used by the operating environment). User agents SHOULD also
> allow users to override author assigned keys with their own key
> assignments (UAAG 1.0 - Checkpoint 11.3). [4] If a user chooses to
> change the key binding, the resultant user-defined remapping SHOULD
> persist across sessions.
> 
> If no key attribute is specified, the user agent SHOULD assign a key and
> alert the user to the key mapping and the resultant user agent assigned
> key SHOULD persist across sessions.
> 
> 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).
> 
> A conforming user agent SHOULD also provide a centralized view of the
> current access key assignments (UAAG 1.0 - Checkpoint 11.1, UAAG 1.0 -
> Checkpoint 11.2). [5] [6]
> 
> --- END PROPOSED RE-WORDING ---
> 
> References:
> 
> [1] User Agent Accessibility Guidelines (UAAG 1.0)
> W3C Recommendation (17 December 2002).
> editors: Gunderson, Jon; Hansen, Eric; Jacobs, Ian;
> URI: http://www.w3.org/TR/UAAG10/
> 
> [2] UAAG 1.0, Checkpoint 9.5
> http://www.w3.org/TR/UAAG10/guidelines.html#tech-configure-no-handlers
> 
> [3] UAAG 1.0, Checkpoint 1.2
> www.w3.org/TR/UAAG10/guidelines.html#tech-device-independent-handlers
> 
> [4] UAAG 1.0, Checkpoint 9.6
> http://www.w3.org/TR/UAAG10/guidelines.html#tech-query-handlers
> 
> [5] UAAG 1.0 - Checkpoint 11.3
> http://www.w3.org/TR/UAAG10/guidelines.html#tech-configure-input
> 
> [6] UAAG 1.0 - Checkpoint 11.1
> http://www.w3.org/TR/UAAG10/guidelines.html#tech-info-current-ua-config
> 
> [7] UAAG 1.0 - Checkpoint 11.2
> www.w3.org/TR/UAAG10/guidelines.html#tech-info-current-author-config
> 
> 
> ----------------------------------------------------------------
> CONSERVATIVE, n.  A statesman who is enamored of existing evils,
> as distinguished from the Liberal, who wishes to replace them
> with others.         -- Ambrose Bierce, _The Devil's Dictionary_
> ----------------------------------------------------------------
>              Gregory J. Rosmaita, oedipus@hicom.net
>   Camera Obscura: http://www.hicom.net/~oedipus/index.html
> ----------------------------------------------------------------

Received on Thursday, 15 May 2008 16:13:39 UTC