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

Hello,

Al's comments below suggest both that (a) the current checkpoint 7.6
may not provide adequate navigation support to the user and that 
(b) without additional study of the problem, he would not feel 
comfortable offering an alternative. [Al, please correct me if
I've misstated these points.]

Based on these comments, here are some ways of moving forward:

1) Leave the checkpoint as is. Add commentary to the
   techniques document (e.g., based on what Al has written) 
   to give developers a clear sense of what users
   need, even if the checkpoint is only about element types.

2) Lower the priority of the checkpoint to a P3. Rationale: if the
   checkpoint is not known to lower important barriers to access
   as written, but is likely to improve accessibility, then it should
   only be a P3 checkpoint.

3) Delete the checkpoint.

Al's comments suggest that his expectations about what the user
needs may not be easily turned into an algorithm ready-made 
for developers, without further study. I do not have an alternative 
checkpoint to propose at this time.

 - Ian

Al Gilman wrote:
> 
> 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

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Thursday, 31 August 2000 14:02:26 UTC