Re: headers attribute (was Re: Form elements)

Leif Halvard Silli wrote:
> Anne also made the point about authors mispelling headers. But do we know why they mispell it? I think because no web features that those authors can sense relies upon it. And so they don't sense their misdeeds.

Since we know authors also commonly misspell attributes that do have a 
visual impact [1], the impact of the rest of your argument is somewhat 
muted at best.

> But if, as the HTML4 spec suggestes, «the [headers] attribute may also be used in conjunction with style sheets», then suddenly we would be in another situation. And authors would have insentives to use it and get it right. The fact that no _visual_ stylesheets relies on the headers selector _of course_ a) make headers little used, and b) does not create an author incentive for creating correct syntax (i.e. for spelling headers right).
> 
> <http://www.w3.org/TR/html401/struct/tables.html#adef-headers>

The headers in question being referenced are going to be the elements 
with the corresponding IDs, which are already easily selected/styled today.

> Hence, what if we allowd headers="" to take single CLASSess as value, and not just multiple ID's. That, and to make it possible to use headers as CSS selectors. Let us say that I could, via CSS, use a single cell's headers attribute to ask that cell who its header cells are. That would soon become interesting even for GUA users. And it would provide visual authors with a visual way of checking that their design is not broken for screen readers. And it would be much simpler for authors to see (visually) which header cells the data cell belonged to.

* How then is existing AT supposed to associate the cell to its header, 
if you don't identify the header IDs in the headers attribute and put 
class names in instead?

* If you want to style a cell's headers today, since the header value is 
the IDs of the header cells, then all you do is just style those IDs. 
You do not need to give headers duplicate functionality of the class 
attribute.

> The advantage of letting headers="" take class is that one could «light up» a cell's header cells  without selecting via the headers attribute. It would also be "faster"/more simple for authors. But it would not provide a way to check whether I spelled headers="" correctly, unless headers somehow could be used as a selector.

Since you can already select the header cells via the IDs, your use case 
boils down to making authors spell-check "headers".  This is not a valid 
reason to change the functionality of the headers attribute.

> (In my head, all this was also related to Maciej's, to my taste, too clear division between CSS and HTML - in the parallell thread about 'role'.)
> 
> 
>> So the key questions, in my opinion, are:
>>
>> 1) How much content is out there that uses headers="" correctly? Not  just 
>> tutorials but actual live web sites that use it on their table  markup. Bonus 
>> points if they use it correctly.
> 
> If headers has a potential of doing someting scope can't, then we should try to make the potential reality. We could also ask: how many _authors_ (those that take AT seriously) use it? It is cool that a authors in the know could use scope most of the time. But what I he really want to make a spiffy table and tabel presentation for his audience? Then he soon need headers="". Just like there is much CSS I don't use daily. But it is good to have when one need it. And, as suggested above,  headers could be made usable even for CSS.
> 
> We do not calculate this way about the different properties of CSS. THere are quite a few CSS propertis which are not very often used and also badly supported. But we do not suggest ditching them therefore. (Ok, I know you want to keep CSS2.1 «real», and therefore move unsupported properties to CSS3 and so on ... i.e. you do not ditch them!)
> 
>> 2) It's been stated that existing screen readers have better support  for 
>> headers="" than scope="". Can we quantify this? What are the most  popular 
>> screen readers and what is their approximate market share?  What is the user 
>> experience in each for a table marked up with  scope="", a table marked up 
>> with headers="", and a table that is not  annotated at all?
> 
> Given that representatives from graphical UA vendors have spoken so much againts the incentives for supporting headers, this is a question in right time. We should even qualify which UA vendors that should have an incentive of supporting it. Does Safari make use of either scope or headers, for instance? I am not in the know.
> 
> That said, it would be great if I did not need to be blind in order to design with headers properly: CSS and headers="" must be coupled.

You're in good shape then, because you don't need to be blind or have 
new CSS abilities to use headers.

What you propose probably falls out of our scope anyway and into the CSS 
working group.

>> For features that are primarily handled by browsers rather than  assistive 
>> technologies, these are the kinds of questions we  investigate. The current 
>> use share breakdown is approximately 80% IE,  15% Firefox, 5% Safari, 1% 
>> Opera. Other browsers are all  significantly below 0.1%. Most people have all 
>> of these browsers  readily available so they can test things. So we tend to 
>> have good  information about how various constructs work in the browsers  
>> actually used by users.
>>
>> But I'd guess most of us don't even know what the top screen readers  are, 
>> and we certainly don't have access to do extensive testing. So  we'll need 
>> help gathering this kind of information.
> 
> Yep. 


-- 
Bill Mason
Accessible Internet
w3c@accessibleinter.net
http://accessibleinter.net/

Received on Friday, 1 June 2007 03:04:17 UTC