Re: headers attribute (was Re: Form elements)

On 2007-05-31 20:45:34 +0200 Maciej Stachowiak <mjs@apple.com> wrote:

> On May 31, 2007, at 10:41 AM, Laura Carlson wrote:

>> Anne van Kesteren wrote [2]:
>> 
>>> The arguments for removing it are that the feature isn't widely used

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. 

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>

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.

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. 

(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. 

> 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. 
-- 
Leif

Received on Friday, 1 June 2007 01:46:14 UTC