Re: headers attribute (was Re: Form elements)

Examples of headers usage "in the wild":
I did a serach on google for "data table" and found these from that
search or pages linked to results form the search


http://www.eere.energy.gov/consumer/your_home/water_heating/index.cfm/mytopic=13220
http://www.eere.energy.gov/consumer/your_home/designing_remodeling/index.cfm/mytopic=10220
http://www.nei.nih.gov/eyedata/pbd_tables.asp
http://www.eia.doe.gov/cneaf/coal/page/acr/table7.html
http://www.eia.doe.gov/cneaf/coal/page/acr/table13.html
http://www.bls.gov/webapps/legacy/cpsatab2.htm
http://data.bls.gov/GQT/servlet/InitialPage (need to fill out form
info to retrive particular data tables)

Yahoo table widget implements headers
http://developer.yahoo.com/yui/examples/datatable/enhanced.html

On 30/05/07, Patrick H. Lauke <redux@splintered.co.uk> wrote:
>
> Thomas Broyer wrote:
>
> > On the other hand, it has been proven that:
> > * headers= isn't used that much in the wild
>
> Due to poor authoring tool support.
>
> > (so current AT –which
> > have been said to poorly support scope=, so I suppose they support
> > *only* headers= for data-cell/headers-cell associations– can't make
> > most tables as accessible as they could with the kind of heuristics
> > HTML5 provides; in other word, they're not really usable yet –as far
> > as I understood what was said on this list–, at least wrt table
> > accessibility)
>
> headers currently work in the most consistent way. Scope works in most
> simple cases, but not necessarily with complex tables...meaning that
> those authors relying purely on scope for complex tables are (knowingly
> or unknowingly) creating tables that are, if not completely
> inaccessible, at least illogical to screen reader users.
>
> > * when used, it's often broken (header= instead of headers=)
>
> To me, that's completely irrelevant. This is like saying "many people
> can't type 'accommodation', so we should change the dictionary and drop
> the second 'm' entirely". Partly related to the bad authoring tool
> support as well.
>
> > Maybe it would need some more rules, e.g. a TH with no scope= in the
> > second column (resp. second row) is automatically affected a scope=row
> > (resp. scope=column) if the cell in the first column of the same row
> > (resp. the first row of the same column) is a TH with no scope= or
> > with scope=row (resp. scope=column).
> > That way, a table with e.g. two lines of TH column-headers (with the
> > first line having some cells spanning multiple columns) wouldn't need
> > scope= at all.
> >
> > However, with such a rule, I wonder whether scope=row and scope=column
> > would be need then… 'cause I've never been shown a table so complex
> > that this would be needed.
>
> Just to clarify: I'm all in favour of standardising these sorts of
> heuristic behaviours in the spec for tables lacking scope or headers
> attributes. But, since HTML 5 wants to specify current usage as well as
> expand the language, and standardise current practice and current
> behaviour, I can't see how this could be reconciled with simply not
> mentioning an attribute like headers which, despite playing the numbers
> game and saying it's not used much, is in fact in spec in HTML 4, and is
> demonstrably supported by current user agents. Unless HTML 5 UAs should
> deal with headers attributes as they would with any other
> unknown/out-of-spec attribute.
>
> What I'm getting at, basically: if HTML 5 wants to do away with
> versioning, and support current markup, how can it NOT at least define
> the headers attribute, even if it then marks it as "deprecated" or
> however this sort of thing will be handled in the future spec?
> Generally, if there's no versioning, shouldn't *everything* that is in
> the HTML 4.01 spec also be found in HTML 5? At least all the things
> currently implemented by UAs? (As much as I'd hate it, this would also
> include things like width/height/etc attributes on table cells, for
> instance...not that I want to see these recommended for use, but
> following the reasoning of 'standardising current browser behaviour',
> they probably need to be mentioned as well, no?) Trying to understand
> how deep this concept of unversioned support of all that was and all
> that will be runs...
>
> P
> --
> Patrick H. Lauke
> ______________________________________________________________
> re·dux (adj.): brought back; returned. used postpositively
> [latin : re-, re- + dux, leader; see duke.]
> www.splintered.co.uk | www.photographia.co.uk
> http://redux.deviantart.com
> ______________________________________________________________
> Co-lead, Web Standards Project (WaSP) Accessibility Task Force
> http://webstandards.org/
> ______________________________________________________________
> Take it to the streets ... join the WaSP Street Team
> http://streetteam.webstandards.org/
> ______________________________________________________________
>
>


-- 
with regards

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

www.paciellogroup.com | www.wat-c.org

Received on Monday, 4 June 2007 15:34:59 UTC