Re: table headers - clear description of problem

Hi Stephane,

> Which leads to the conclusion that the headers/id constructs should be kept
> in the spec as a complement to the scope method, as it has *some* uses that
> cannot be done with scope.

That is what we have been arguing all along, the additon of a scope
alogorithm that provides the required associations correctly without
the need to use the more cumbersome headers/id method is great. It
means that in the majosiry of cases use of id/headers will not be
needed.

Unfortunately a scope based algorithm does not do the job for some
complex and irregular tables. hence the need for headers being
extended to reference td.

Without more robust support for id/headers in HTML5  either  tables
will have  to be redesigned or a second version provided to fit the
limitations of the accessibility features available in HTML5 or the
id/headers can be used and the result will be non-conformant. In my
day to day work, while I can suggest simplicity to overcome a
limitation of html features, it often dosn't wash with clients, who
are often quite specific in their requirements.

btw
The issue of id/headers being being more prone to authoring errors is
not one we encounter much, as we are usually dealing with vendors of
web based applications, and once the id/headers associations rules are
built in the back end, the many permutations of output data tables
which require their use are generated automatically without error.

regards
stevef

2008/9/2  <stephane.deschamps@orange-ftgroup.com>:
>
>
> -----Message d'origine-----
> De : Joshue O Connor
> Envoyé : vendredi 29 août 2008 16:31
> Objet : Re: table headers - clear description of problem
>
>>>> Why not mark all the header cells as <th> and enable hierarchical
> headers by
>>>> allowing a <th> cell to point to another <th> using the headers
> attribute?
>>>
>>> At the moment, nested headers aren't allowed. If the spec is changed
>>> so that they are allowed, I wouldn't want header elements in the
>>> middle of a data table, as the header wouldn't apply to the row or
>>> column it's in, but a conceptual header for the cells that reference
>>> it. Allowing the headers attribute to reference a td is logical,
>>> simple, and it works in current implementations.
>>
>>I agree. I think the conceptual headers approach means that we can still
>>use *pure* headers as they were intended and allow td cells to reference
>>others so they can behave like headers as needed.
>
>
> Which leads to the conclusion that the headers/id constructs should be kept
> in the spec as a complement to the scope method, as it has *some* uses that
> cannot be done with scope.
>
> (as in: it's not just a problem of a specific UA or accessibility tool that
> does not implement scope properly, it's also a broader problem that should
> be kept in mind)
>
> --
> Kind regards,
> Stéphane Deschamps
> FT/ROSI/DDSI/APT/ IT Accessibility
>  Web HCI expert
>  orange / france telecom group
>
>
>
> *********************************
> This message and any attachments (the "message") are confidential and intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
> ********************************
>
>



-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html

Received on Tuesday, 2 September 2008 12:39:24 UTC