RE: H43 and header cell relationships

Olaf, the first step I would do is to try to validate or disprove the
possibility of a nesting/serial access approach.  Is it possible to design
a table where a references b and b references c but a should not reference
c?  If that's possible then you can't rely on this serial type approach.

Jonathan

-----Original Message-----
From: Olaf Drümmer [mailto:olaf@druemmer.com]
Sent: Wednesday, February 19, 2014 5:19 PM
To: W3C WAI ig; Matt Tongue
Cc: Olaf Drümmer
Subject: Re: H43 and header cell relationships

I think I have to correct my statement:
HTML seems to require (as Sailesh points out) that indeed the headers
attribute of table cell has to list the ids of all the header cells with
which it is associated.

Sorry for any confusion my statement might have caused.

I nevertheless would like to add that I think that this approach is
conceptually wrong - nested semantic structure should be expressed via
nested representation of pertinent data / attributes. Even if one were to
agree though with my reasoning it's probably a bit late in the game to
have this addressed...


Olaf



On 19 Feb 2014, at 22:46, Olaf Drümmer <olaf@druemmer.com> wrote:

> As far as I can tell, any cell should identify only its direct header
cell parents. Nested header cell relationships would then be represented
by nested use of the headers attribute.
>
> Olaf
>
> On 19 Feb 2014, at 22:09, "Tongue, Matt" <Matt.Tongue@nrc-cnrc.gc.ca>
wrote:
>
>> When marking up a table with multiple levels of headings, is it
mandatory to always put all header cell IDs into the headers attribute of
a cell?
>>
>> For example, if a data cell has 3 header cells, but the 2nd header
cell's headers attribute references the 1st header's ID, would it not
suffice for the data cell to just reference header cells 2 and 3, since
header cell 2 references header cell 1 (thus creating a relationship
already)? Or must every header always be identified for every cell, no
matter what?
>>
>> Reference: http://www.w3.org/TR/2013/NOTE-WCAG20-TECHS-20130905/H43
>>
>
>

Received on Thursday, 20 February 2014 13:52:21 UTC