Defect 13174

Hi Leonie,

Regarding this defect:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13174

The issue here is that for a table object in the accessibility API you need
to be able to get the header for a given cell. This text of the header that
would be read would have to be a concatenation of all the text content in
the cell. If we were to do something like a list. This could be a VERY long
name and not necessarily helpful. Imagine moving form row 1, column 2 and
announcing the table header and hearing this long name derived from the
concatenation of the text content in the block element.

Now, if a table header has a list within it I would argue that the table is
actually being used for layout because having say an ordered list in a
table header is really not a header. The table would appear to be used as a
layout tool to align the list items with list items in other column
headers. This would go against what Ian argued for which was to use tables
as layout aids.

The second problem occurs if you are inserting headers (h1, etc.) within a
table header. That would confuse the structure of the document and again
the only reason I can think an author would want to do this would be to use
a table as a layout aid. Headers don't actually represent a block of
content - a frustration I have with HTML. If you are going to have a header
it should be a container for a section where the header represents the
container's name. Rather, in HTML, headers could be sprinkled all over a
number of table cells and the table is used as a layout aid. Computation of
the table header is more acceptable unless you have lots of headers in the
same cell and then there is a concatenation process that needs to occur to
compute the header name.



Rich

Rich Schwerdtfeger
CTO Accessibility Software Group