[Access Module] Proposed Rewording for sections 3.1, 3.1.1 and 3.1.2

Aloha!

First, the User Agent Working Group (UAWG) thanks the XHTML2 WG for the 
opportunity to review and propose stronger wording for sections 3.1, 
3.1.1., and 3.1.2 of the Access Module. The proposed re-wording, which 
follows my signature, is based on the editor's draft of the Access 
Module located at:

http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080418/

After each "heading" in the proposed text below, you will find a URI 
which points to the UAWG's wiki pages concerning the re-wording, so 
that you can compare the original and proposed rewording in context.

Second, any questions or issues arising from the proposed re-wording
should be cross-posted to both the XHTML2 public list: 
public-xhtml2@w3.org AND to the UAWG's public list: w3c-wai-ua@w3.org

For those of you interested in the genesis/synthesis of this rewording,
please consult the archives for the UAWG's publicly archived emailing 
list:

http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/

especially:

1. minutes of the supplemental UAWG meeting on Access Module:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0098.html

2. the thread that unspools from:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0090.html

3. minutes of the UAWG meeting of 8 May 2008:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0088.html

and the thread that unspools from the notice of proposed re-wording on 
the UAWG wiki:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0082.html

Thank you again for this opportunity -- the UAWG is confident that the 
proposed re-wording makes the entire draft tighter and more 
interoperatively implementable, and is confident that the XHTML2 WG 
will find the UAWG's proposed revisions appropriate,

Gregory J. Rosmaita (on behalf of the UAWG - http://www.w3.org/WAI/UA)

NOTE 1: the User Agent Accessibility Guidelines [1] need to be added to 
the list of normative references for the Access Module.

NOTE 2: while i am confident that the following is an accurate 
reflection of the working group's final consensus, any errors 
contained within the following are my own as an individual; for 
cross-reference, please consult:

* http://www.w3.org/WAI/UA/wiki/AccessModule
* http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0098.html
* http://www.w3.org/2008/05/13-ua-minutes.html


--- BEGIN 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 SHOULD 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. 

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

----------------------------------------------------------
He that will not apply new remedies must expect new evils; 
for time is the great innovator.      -- Sir Francis Bacon
----------------------------------------------------------
            Gregory J. Rosmaita: oedipus@hicom.net
        Camera Obscura: http://www.hicom.net/~oedipus/
    Oedipus' Online Complex: http://my.opera.com/oedipus/
United Blind Advocates for Talking Signs: http://ubats.org
----------------------------------------------------------

Received on Wednesday, 14 May 2008 02:25:14 UTC