RE: Defect 13174

Rich,

http://www.w3.org/Bugs/Public/show_bug.cgi

    Realised today that this had completely disappeared off my radar. It looks as though the bug has been closed fixed, and that the spec will be updated to allow flow content (with certain restrictions).

"Rationale: I've allowed all flow content except <header>, <footer>, heading,
and sectioning content, based on the discussions above."

    The example that seems to have been particularly persuasive is on this page:
http://cdl.ru/categories_in_item.mhtml?CatID=3&ShortID=945
    I'm not sure what makes this example compelling. It strikes me that the <th> content would be better represented as part of the table content instead.

    The code example that was filed with the bug seems to re-enforce the idea that design is the deciding requirement, not semantics:

<th>
    <dl>
        <dt>Actual header</dt>
        <dd>Additional content that, by visual design,
        cannot be represented as a separate table cell</dd>
    </dl>
</th>

    Think we should consider re-opening this bug? The user experience (for AT users at least) if block level content is allowed inside a <th> isn't likely to be good IMHO.

Léonie.




--
Nomensa - humanising technology

Léonie Watson, Director of Accessibility & Web Development
tel: +44 (0)117 929 7333
mob: +44 (0)792 116 8551
twitter: @we_are_Nomensa @LeonieWatson

Nomensa Email Disclaimer: http://www.nomensa.com/email-disclaimer



________________________________
From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: 22 September 2011 18:03
To: Léonie Watson
Cc: jf@stanford.edu; public-html-a11y@w3.org
Subject: 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