- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Fri, 27 Aug 2004 16:03:00 -0400
- To: www-html@w3.org
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