Re: A table navigation technique

Hi, Daniel
I would agree with what you about the need for a more precise definition of
table linearization.

With regards to your example, a solution that I found helpful was to
"normalize" by replacing a spanned cell with smaller cells which are
duplicates of the spanned cell.  (Duplicate cells have a note that they
are span.)  The duplication of the spanned cells helped to
simplify table navigation.


Your example would look like:
                                  Month    Month(span)   Month(span)  Month(span)  
                                  January  February      March	      April  
Ville         South         Nice      13        14          15           16  
Ville (span)  South (span)  Cannes    14        15          16           17  
Ville (span)  North         Paris      5         6           7            8  
Ville (span)  North (span)  Lille     -3        -2          -1            0  

Another approach is just to fill the added cells with a note that it is
a spanned cell and indicate which cell was spanned.

Rendering options can control what labels to include in a cell, e.g.
most restrictive ("Nice"), total ("Ville  South  Nice").  Allowing
this type of control for both row headers and column headers
gives you most of the variations you mentioned, except for mark-up.
However, the span notation could help blind users to understand about the
mark-up.

Scott


> > Hi,
> > Here are a few reasons I've come up with for making table serialization
> > a priority 1 item.
> 
> I think we need to define more precisely what we mean by table
> linearization.
> 
> Off http://wwww.w3.org/WAI/ER/WG, there are some notes
> on configuration for table linearization that address the proxy tool
> but are also applicable for native browser.
> 
> 
> Basically, good table linearization needs to support control for
>    - orientation (row, column, markup)
>    - repetition (none, header, cell)
>    - interaction (none, row/column, cell, search)
> 
> Examples of output, for the table:
> 
> <TABLE border=1 summary="une chose a preciser">
> <CAPTION ALIGN=TOP>Temperature in some French towns</CAPTION>
> <TR><TH colspan="3" rowspan="2"><TH colspan=4 scope="colgroup">Month
> <TR><TH>January<TH>February<TH>March<TH>April
> <TR><TH rowspan=4 scope="rowgroup">Ville
> <TH rowspan=2 scope="rowgroup">South
> <TH scope="row">Nice<TD>13<TD>14<TD>15<TD>16
> <TR><TH scope="row">Cannes<TD>14<TD>15<TD>16<TD>17
> <TR><TH rowspan=2 scope="row">North
> <TH scope="rowgroup">Paris<TD>5<TD>6<TD>7<TD>8 
> <TR><TH scope="row">Lille<TD>-3<TD>-2<TD>-1<TD>0
> </TABLE>
> 
> 
> 
> Orientation: row
> Repeat: All headers for each cell 
> 
> Ville, South, Nice, Month, January: 13,  
> Ville, South, Nice, Month, February: 14,  
> Ville, South, Nice, Month, March: 15,  
> Ville, South, Nice, Month, April: 16
> Ville, South, Cannes, Month, January: 14,  
> Ville, South, Cannes, Month, February: 15,  
> Ville, South, Cannes, Month, March: 16
> 
> or
> 
> Orientation: column
> Repeat: Deepest header for each cell
> 
> Data:
> January, Nice: 13
> January, Cannes: 14
> January, Paris: 5
> January, Lille: -3
> February, Nice: 14
> ...
> 
> or
> 
> Orientation: row
> Repeat: Deepest header for each row
> 
> January/February/March/April
>  Other (not used) Row header names: Ville, South/North
> 
> Nice: 13, 14, 15, 16
> Cannes: 14, 15, 16, 17
> ...
> 
> or
> 
> Orientation: markup
> Repeat: Not applicable
> 
> 
> Month
> January February March April
> Ville South Nice: 13, 14, 15, 16
> Cannes: 14, 15, 16, 17
> North Paris: 5, 6, 7, 8
> Lille: -3, -2, -1, 0
> 
> 
> etc
> 
> 
> =============
> 
> So which level of configuration should mainstream browser support ?
> 
> Lynx just supports Markup, which means ignoring the table markup really.

Received on Monday, 16 November 1998 23:55:51 UTC