W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2008

[Access Module] new editor's draft with new attribute @order

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Wed, 13 Aug 2008 18:27:32 +0100
To: wai-xtech@w3.org, w3c-wai-ua@w3.org
Message-Id: <20080813171824.M21244@hicom.net>

http://www.w3.org/MarkUp/2008/ED-xhtml-access-20080813/

key changes:

key change 1. Tighter verbiage for Section 3.1.2. (definition of key 
attribute)

<q 
cite="http://www.w3.org/MarkUp/2008/ED-xhtml-access-20080813/#sec_3.1.2.">

The key attribute represents an abstraction. The use of the name "key" 
for this attribute is historical and does not mean that there is any 
association with a specific "key" on a keyboard, per se. It is up to 
the user agent to provide a mechanism for mapping the document 
character set value(s) of the attribute to the input methods available 
to the user agent. For instance, on some systems a user may have to 
press an "alt" or "cmd" key in addition to the access key. On other 
systems there may be voice commands, or gestures with a mouse, an eye 
tracking input device, etc. Regardless of the mechanism, the result is 
that it appears to the access element processor as if the defined key 
was entered.

A user entering any of the access keys 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). Note that it is 
possible to deliver alternate events via [XMLEVENTS]. Note also that the 
concept of navigation order is a property of the Host Language, and is 
not defined in this specification.
</q>

key change 2: the former section 3.1.3 is now section 3.1.4 due to the 
addition of the order attribute, at the request of the SVG working group:

<q 
cite="http://www.w3.org/MarkUp/2008/ED-xhtml-access-20080813/#sec_3.1.3.">

3.1.3. order = ( document* | list )

The order attribute indicates how this access element should determine 
the navigation order for its matching elements. The default value, 
document, indicates that the items MUST be traversed in document order. 
The alternate value, list, indicates that the navigation order of 
matching elements is determined by the author-defined order of items in 
the list of targetid or targetrole attribute values.

For the sake of determining navigation order, elements in the document 
that match the values in the targetid or targetrole attributes are called 
matching elements, and all elements that match the same value are members 
of an element group. Note: since the id of an element must be unique 
within a valid XML document, in such documents, each element group based 
on targetid values consist of no more than one matching element.

For each navigation operation, the navigation order for both 
document-order and list-order is sensitive to the current focus 
element. For document-order, if no element currently has focus, the 
first matching element in the document MUST be the focus target; if an 
element does have focus, the next matching element in the document MUST 
be the focus target. For list-order, the focus target navigation order 
is determined as follows:

    * If no matching element of this access element currently has 
      focus, the focus target MUST be the first element in document 
      order that matches the first element group. If there is no such 
      element, then the focus target is the first element that matches 
      the second element group, and so on.

    * If a matching element of this access element already has focus:

         1. If there are additional matching elements of the same 
            element group in document order, then focus MUST be sent 
            to the next matching element of the same element group.

         2. Otherwise, focus MUST go to the first matching element 
            (in document order) of the next element group.

         3. If there are no remaining elements groups, then the search 
            MUST resume from the first element group.

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.
</q>

please note as well, that the XHTML2 WG is also considering the issue 
of indicating the "key" to be used, especially in light of the ability
of the user to re-map the author defined key-binding to one of the 
users' choice; obviously, if the re-defined key is present in the "label"
for the element for which access has been defined, what then?

any and all suggestions are quite welcome,
gregory.

gregory.
---------------------------------------------------------------
DELIBERATION, n.  The act of examining one's bread to determine
which side it is buttered on.
                         Ambrose Bierce, The Devil's Dictionary
---------------------------------------------------------------
           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, 13 August 2008 17:28:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:52:01 GMT