Re: 'nextFocus' attribute -- lift it to a 'tour' structure

At 3:42 PM +0200 10/20/04, Steven Pemberton wrote:
>Al,
>
>In HTML4, there were two options for link traversal: either accept 
>the linear order as implied by the structure of the document, or, 
>even if you only wanted to reorder two links, number every link in 
>the document to give the required order, and keep that up to date 
>every time you added a link.
>
>The proposal for XHTML2 is to just mark (pairs of) links that don't 
>follow the implied document order, which for authoring is an order 
>of magnitude easier to do, and trivial to keep up to date. I would 
>strongly disagree that it is just as view-specific as fontFace is, 
>because it is simply layering an alternate navigation structure over 
>the implied structure.

Thank you for this clarification I certainly missed you intent.

>As I understand it, you are proposing to take reinstate the old 
>method, but out of line from the document (a sort of metadata). I 
>understand that this would make different orders possible, but I 
>disagree with your claim "There is no one universal tour for a given 
>content structure." Personally I have never had the need for other 
>tours than the default one, let alone different ones for different 
>views. I can understand that there may be occasions where other 
>tours are needed, but not in the absolute way that you claim.

The only absolute I claimed is that one navigation order per page is
not sufficient in general, for all users of all pages. We need an
architecture that allows for the definition of alternate orders or
spanning nav trees.

>It is certainly not clear to me that your proposal "is more 
>efficient than the solution in the present draft and at the same 
>time more robust (resistant to author errors where one element in 
>middle of tour is dropped in edits)."

Agreed.  I was assuming that the old algorithm applied.

On the other hand, it would appear there are some problems with the current
approach still. If the nextFocus provides a skip forward, then the focus
cycle will *always* skip the intervening focusable entities no matter
how many times around the page and back over again the user iterates
with a "next focus please" user command.  Unless there is a nextFocus
somewhere that will indeed be visited that gets you into that range.
Likewise should the nextFocus move you backward in document
order, there will be a tight loop formed from which the user never
escapes to perceive the rest of the page.

These smell enough like failure modes for this navigation mode so as 
to bear another look.

Will authors conclude again that if they need to re-order any pairs, 
they need to specify the order of all?

Then we get back to de_facto the situation that I was commenting on initially.

>It seems that to achieve what you are proposing, a value for the 
>proposed "role" attribute could be applied to existing <nl> 
>elements, and achieve the same effect.

Yes, and we do count that as a technique to be used.

On the other hand, just to set the tabbing order, an attribute of
type IDREFS is clearly more compact than a full <nl>.

The <nl> solution gives a "hit the high spots" focus tour [if the
default algorithm is a breadth-first walk of the navigation waypoint
tree] -- without adding the nextFocus attribute. And a natural way to
refine beyond the "high spots" once one is 'warm' in the search for
"the beef."

PF is having a Face-to-Face on 27,28 October next week in San
Francisco. Could you designate someone [other than Rich] versed in
the design rationale for this feature to join that meeting -- even
remote -- for a while, for a discussion of navigation modes and their
proper data structure classes as it affects this feature design? I
would like to do what I can to increase the intergroup bandwidth on
this point in search of a resolution. We can probably schedule this
point at your convenience.

http://www.w3.org/WAI/PF/Group/meetings/f2foct04.html

Al

>Best wishes,
>
>Steven Pemberton
>
>Al Gilman <Alfred.S.Gilman@IEEE.org> wrote:
>>http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html#adef_hyperAttributes_nextfocus 
>>Summary of as-in-draft:
>>Transitive closure of nextFocus arcs defines one tour hardwired into
>>the content.
>>
>>Feature replaced:
>>http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex
>>
>>Recommeded alternate strategy:
>>Tours to be implemented by out-of-line structures collecting references
>>to tour stops.  This strategy covers both
>>- hierarchical intrapage navigation with author-nominated hotspots 
>>and branches
>>- simple linear tours ordering author-nominated hotspots.
>>
>>The latter case can be covered by a <tour> element with an
>>attribute of type IDREFS that lists the tour stops in order.  This is
>>more efficient than the solution in the present draft and at the same
>>time more robust (resistant to author errors where one element in
>>middle of tour is dropped in edits).
>>
>>It is also architecturally better, as tours are view-specific, best 
>>if adapted
>>to the delivery context.  The 'nextFocus' attribute is view-specific just
>>as fontFace is.
>>
>>Discussion:
>>
>>Tours are functionality that should adapt to the delivery context.
>>There is no one universal tour for a given content structure.
>>
>>The best tour for an eyes-free user (such as a screen reader user) is
>>likely a breadth-first walk of the page Table of Contents.  This
>>resembles the left nav bar which is a tour of the vicinity abstracted
>>using the structure of the site map.
>>
>>The best tour for a high-input-event-cost user (such as a switch
>>user) is likely a sweep of all activatable element in descending
>>order of click-through frequency as determined from the server logs.
>>This resembles the right highlights bar which is a tour of the vicinity
>>in a concept net topology.
>>
>>Strategy:
>>
>>So the behavior should be cast in the standard framework.
>>
>>A tour is a selection and ordering of tour stops with iterate and
>>optionally initiate methods.
>>
>>In this way a tour is cut from the same cloth as the 'find,' 
>>findNext' service.
>>
>>The declarative part of a tour is
>>
>>a) an order-significant list of the tour stops -- this can be one
>>attribute of type IDREFS b) a 'nextInTour' event bound to this list
>>c) [optionally] a 'startTour' event bound to this list.
>>
>>The initial default navigation behavior is defined by the XHTML 2.0
>>specification by a standard reference method that handles the events
>>declared above and computes where to go based on the current focus
>>and the list defining the succession. But this means that this is not
>>the only possible behavior.
>>
>>This construction allows multiple tours to be defined and
>>communicated by the author.
>>
>>It allows the User Agent and/or AT to replace the author-nominated
>>tour through the established event capture mechanism [to be confirmed
>>by careful review].
>>
>>Al

Received on Wednesday, 20 October 2004 15:24:39 UTC