Linearising layout tables

Linearising a table is straightforward: I could add this capability
to the accessibility proxy in perhaps an hours work.  The harder task
is to determine when a table is for layout and should be linearised.

The parser can look for structural markup: any more structural detail
than the existence of <th> elements will presumably mean that a table
is genuine.  OTOH, the converse is not true, so this is of limited
value as a criterion for determining how to deal with it.

That raises the question, what harm does it cause if the proxy
makes an incorrect assumption?

We have four outcomes regarding a table:

1. the table is structural, and is correctly diagnosed as such.
2. the table is structural, but is misdiagnosed as layout.
3. the table is for layout, and is correctly diagnosed as such.
4. the table is for layout, but is misdiagnosed as structural.

In case (3) the table will be beneficially linearised. In cases (1)
and (4), the table will be untouched, so we can discount these.
The problem arises in case (2): how much harm is done if we
accidentally linearise a structural table?

One possible thought is to take a conservative approach and treat
a table as layout if and only if every cell is a <td>, and no
element has any structural attribute (abbr, axis, headers, scope).

Even using such a conservative approach, we will sometimes
incorrectly linearise a table.  So the question is: how much
harm could this do?  Anyone ever considered this problem?

-- 
Nick Kew

Available for contract work - Programming, Unix, Networking, Markup, etc.

Received on Wednesday, 8 May 2002 13:31:53 UTC