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

Re: (PFWG) ACTION-211 Query re: SVG Request for @order for Access Module

From: Shane McCarron <shane@aptest.com>
Date: Thu, 07 Aug 2008 15:23:44 -0500
Message-ID: <489B59D0.5050408@aptest.com>
To: Doug Schepers <schepers@w3.org>
CC: "Gregory J. Rosmaita" <oedipus@hicom.net>, w3c-wai-pf@w3.org, public-xhtml2@w3.org, w3c-wai-ua@w3.org, public-svg-wg@w3.org, wai-liaison@w3.org

See if this makes more sense:

<h3><code>order</code> = <code>"document* | list"</code></h3>

<p>The <aref>order</aref> attribute indicates how this <code>access</code>
element should determine the <em>navigation order</em> for its
<em>matching elements</em>.  The default value,
<code>document</code>, indicates that the items should be traversed in
"document order": the next item in the document that matches any selection
criterion will become the target.  The alternate value, <code>list</code>,
indicates that <em>matching elements</em> are determined as follows:</p>

<ul>
    <li>The values in the <aref>targetid</aref> or <aref>targetrole</aref>
    are evaluated from beginning to end. Elements in the document
    that match are called <em>matching elements</em>, and all elements that
    match the same value are members of an <em>element group</em>.</li>

    <li>If no matching element of this <code>access</code> element
    currently has <em>focus</em>, then focus is sent to the first
    element in document order that matches the first element group.
    If there is no such element, then the first element that matches the
    second element group, and so on.</li>

    <li>If a matching element of this <code>access</code> element
    already has <em>focus</em>:
    <ol>
        <li>If there are additional matching elements of the same
        <em>element group</em>
        in document order, then focus is sent to the next
        matching element of the same element group.</li>

        <li>Otherwise, focus goes to the first matching element (in
        document order) of the next element group.</li>

        <li>If there are no remaining elements groups, then the search
        resumes from the first element group.</li>
    </ol>
    </li>
</ul>

<p>The location of the next <em>matching element</em> MUST be determined
each time the <code>access</code> element is triggered, since it is possible
that between events the contents of the document will have changed.</p>


Shane McCarron wrote:
>
>
>
> Doug Schepers wrote:
>>
>> Is there some reason that the way I've explained it here won't work?
> No - I had just never read that!  That, or a simple variation of it, 
> would work fine.  In the teleconferences, we were discussing @order 
> and that it contained a list of IDREFs or CURIEs.  That's where I got 
> that, and it was stupid.  This makes much more sense.  I will see what 
> I can do with it.
>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Thursday, 7 August 2008 20:24:35 GMT

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