Re: headers attribute (was Re: Form elements)

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/
______________________________________________________________

Received on Wednesday, 30 May 2007 19:24:39 UTC