- From: Scott Luebking <phoenixl@netcom.com>
- Date: Mon, 16 Nov 1998 20:54:33 -0800 (PST)
- To: dd@w3.org, phoenixl@netcom.com
- Cc: w3c-wai-ua@w3.org
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