

Re: A table navigation technique

From: Al Gilman <asgilman@access.digex.net>
Date: Sat, 14 Nov 1998 12:02:41 -0500 (EST)
Message-Id: <199811141702.MAA13666@access1.digex.net>
To: charlesn@srl.rmit.EDU.AU (Charles McCathieNevile)
Cc: phoenixl@netcom.com, w3c-wai-ua@w3.org
to follow up on what Charles McCathieNevile said:

> True table navigation would allow the user to find out where they are in 
> the table, and would apply either the algorithm specified in HTML 4 or 
> use the TABLE attributes and elements to provide additional context, such 
> as headers which apply ot the current cell.
> It would then enable movement to the next cell in a row or column, or 
> along an arbitrarily defined AXIS.
> This is the kind of implementation that would be ideal.
> A User Agent which allowed the user to navigate within a page by 
> element, traversing or ascending/descending the document tree, would 
> provide some of these functions. It would be possible to move across a 
> row, cell by cell, or to move up and down rows. This provides no context 
> information, and requires the user to remember where they are. This 
> strikes me as the minimum acceptable native implementation, assuming that 
> all the information is exposed for a 3rd party product which actually 
> does the job properly.

Element navigation could be limited to walking the parse tree,
but let us not assume it would.  In the case of tables there is
defined column semantics.  Column traversal could also be
supported as navigating the structure defined by the markup.

The range of verbs available for navigation among the elments of
the document, and the extent of display within the local
neighborhood of the logical web around that element are
mix-and-match independent channels in the composition of a
solution.  And it makes sense for the browser itself do do some
of each.

We keep bumping into methods that are feasible through what is
now called style.  CSS2 allows the style rule to query the TITLE
of a link source and inject the TITLE text in a .before

Likewise if we were to define a computed pseudo-attribute I-am-a
and give it a value of the closesest preceeding TH in the current
column and a computed pseudo-attribute I-go-with with the value
of the closest enclosing TH in the current row.  This allows what
has sometimes been called a readout rule to be constructed such
as "The <I-am-a> of <I-go-with> is <current element contents>."

The relationships defined by the document are not just the parse
tree.  Column membership and headers=idref attributes are
examples of graph relationships beyond the tree that are clearly
identified without any guessing by the markup in the document.
And we can consider asking the browser to do a little guessing.
There is plenty of precedent for that in successful browsers.

[One tactical problem is that HTML4 fails to recognize the
distinction between I-am-a and I-go-with relationships.]

These relationships can be exploited as navigation paths and
information retrieval channels for adaptive presentation, as
Scott pointed out with his expanded presentation examples.  This
is just a little more of what has been demonstrated to be
beneficial.  Consider the examples of tool tips populated with
the TITLE attribute, and the role cues of "link" etc. that
clearly are a help in pwWebSpeak.

Here are the sorts of things that I can imagine asking browsers
to do.

1. Support a effective-headers pseudo-attribute for all table
cells.  This is where the guessing algorithm goes: it populates
this pseudo-attribute.  Effective-headers inverts the SCOPE
indication and adds in guessing rules to come up with a list of
the elements forming the logical neighborhood of the current [TH
or TD] element.

2. Subclass effective-headers into i-am-a and i-go-with sublists.
Note that row and column indications are possible values for
these.  For example i-am-a="column 3", i-go-with="row 7".

3. Expose the pseudo-attributes defined above so that they can
be accessed from style rules as attribute values are retrieved.

4. Support this attribute-retrieval function of CSS2.

5. Support the .before and .after etc. per ...

6. Support structure navigation of row and column substructures
in the context menu for any table cell.  Priorities:

	top: next/previous in substructure

	mid: home in substructure (probably first; possibly key)
		trace about- or meta relationships (i-am-a relationships)

	least: pick-from-list for contents of substructure (value of query)
		pick-from-list for superclass tree
		adjust readout pattern for class of current context

7. Support enough elment navigation so that the user can navigate
the current selection to an arbitrary table cell.  

> Charles McCathieNevile
Received on Saturday, 14 November 1998 12:04:26 GMT
