how to distinguish "important elements" (not just type?)

The text of checkpoint 7.6 now reads, with link numbers inserted:

   7.6 Allow the user to navigate efficiently to and among important
          structural elements identified by the author. For markup
          languages with known semantics, allow forward sequential
          navigation to important structural elements. For other markup
          languages, allow at least forward sequential navigation of the
          document object, in document order. In HTML 4 [381][HTML4], the
          list of important elements is: A, ADDRESS, BUTTON, FIELDSET,
          DD, DIV, DL, DT, FORM, FRAME, H1-H6, IMAGE, INPUT, LI, MAP,
          OBJECT, OL, OPTGROUP, OPTION, P, TABLE, TEXTAREA, and UL. In
          SMIL 1.0 [382][SMIL], the list of important elements is: a,
          anchor, par, seq, and switch. In SVG 1.0 [383][SVG], the
          important elements are a and g. [Priority 2]
          Note: Structured navigation of headings, tables, forms, lists,
          etc., is most effective when available in conjunction with a
          configurable view ([384]checkpoint 8.4 and [385]checkpoint
          8.5). User agents should follow operating system conventions
          for indicating navigation progress (e.g., [386]selection or
          [387]content focus).
          [388]Techniques for checkpoint 7.6

I am concerned that here we may have gone a bit too far in striving to be
concrete, so as to be easy to implement.

A key phrase is "important structural elements identified by the author."

The catch is that while motion is only required to elements that the author
has identified as elements, it is not safe to assume that the author has
identified which elements are important, or that these can be determined by
their element _type_ alone.


* More factors than element type:

My current working model for effective structural navigation, and
identifying the "important elements" in any sub-document context, includes
some propositions that do not necessarily turn into an algorithm directly:

- The navigation is hierarchical; the identification of "important
sub-elements" recursive.  If one choses to scan the content below them on
the tree they can move breadth-wise over the subtrees attached at the
current node.

- The navigation tree is an abstraction of the syntax tree.  Not all nodes
in the parse tree are stops in the navigation tree.  

- Fanout matters.  The abstraction of the parse tree will be managed so
that under a given node the number of children tends to cluster around some
sweet spot, perhaps "seven give or take two."

- Balancing quantitative measures of content matters.  The abstraction of
the parse tree will pay attention to the division of content as measured at
least by a) time to read the text and b) number of links enclosed in a
sub-part.  The abstract navigation tree will attempt to approach
eqi-division of these measures or predictors of how likely any given branch
is to contain what the visitor is actually looking for.

- And there are exceptions.  In saying "select ranges should not be too
long" it is an error to break up the list of two-letter postal codes for
the U.S. states and the District of Columbia.  Because the list of these
jurisdictions is something where most users already know the entries (at
least the names of the states) it is not an appeal to short-term recall and
the "seven give or take two" rule does not apply.  This is just one
important exception.  

* Limitations of markup.

Markup languages such as HTML and XML provide both sequence and hierarchy,
but the markup format specifications do not provide adequate support to
know when the hierarchy or sequential order is significant or accidental.
My attitude on this may be unduly colored by my ambition to provide user
agents with something better in the way of markup in the future.  But we
don't yet have either the authoring tool techniques nor the standard markup
practices to implement this 'better' solution.

The problem is that in order to pass critical threshold in the
effectiveness of the abstract navigation tree, I am concerned that it will
take applying more techniques than just checking the element type, but that
reducing the formula to something that is reasonable to ask for will take
more experimentation than we have calendar time for.  If we try to nail
down the navigation tree extraction method with what we know now, there is
a risk that we will not meet the users' needs, impose unreasonable demands
on the User Agent suppliers, or both.

* Summary

I have reservations about classing element types in the definition of this
checkpoint as either "important" or "not important."  

It is a sufficiently multi-dimensional problem, as I see it, that I am
relunctant to draw by guessing a line in the sand on one axis only.
Element type is a very helpful hint in compressing the parse tree, but it
may not be enough information to make the results a winner, and worth
demanding.

What element types have to tell us can probably be represented by an
ordered list of [more than two] groups of element types.  Some types are
definitely more likely to be one of the "important elements" than other
types.  But given just this type-based knowledge, I am not sure we are
above threshold for specifying what constitutes a "reasonable
accomodation."  The end result is at what depth the element shows up in the
navigation tree structure, and not just is it in or out. 

Al

Received on Monday, 28 August 2000 16:37:55 UTC