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

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 Friday, 27 August 2004 20:13:45 UTC