Re: Deliverable for Action 72 @headers

I think there is now general agreement that there is more than one way 
to skin a cat which I think just leaves one more issue to address here.

Gez Lemon wrote:
>> In the specific case of table headers, I have reservations about
>> the current spec, but I recognize that it is in a state where the best way
>> to produce improvements is to see how it fares in actual implementations and
>> under user testing.
>>     
>
> The improvements in this case have been to introduce conformance
> requirements that mean complex data tables cannot be marked up
> accessibly, which doesn't seem like an improvement to me.
>   

I meant "improvements from the current spec to a better spec".

>> People implementing the spec and going "look this user
>> can't understand this type of table because they need more information" is a
>> really strong argument, and really likely to produce a change. In the
>> meantime by not focusing on this issue I hope to free up enough bandwidth
>> for everyone that progress can be made in other areas.
>>     
>
> I raised two bugs [1] [2] with that type of information, and both were
> dismissed in minutes, so I haven't seen evidence so support your
> assertion.
>   

The important point was *implementing the spec* to perform user testing. 
We agree that there seem to be issues with the current spec. The 
strongest way to make the case that these issues need to be addressed is 
to go away and implement the current spec and show how it doesn't work 
e.g. by demonstrating user confusion compared to a different algorithm 
in which headers my themselves have headers. Or to get an implementor to 
explain why they won't implement the current spec in their product.

There are several ways to do this kind of testing; the simplest way 
would be to add the current spec to my Table Inspector (this uses the 
headers attribute behind the scenes so should be compatible with current 
AT); unfortunately I have rather a lot on at the moment and have 
probably already spent too much time discussing table accessibility and 
alt text in the past week. However the source is available if you want 
it. Alternative, better options would be to implement it in open source 
AT. I don't know much about this area; a quick glance at the source code 
for Orca didn't reveal anything HTML-specific so it may well be that 
you'd have to hack Firefox/Webkit to make the change work there; rather 
high effort for prototyping. However something like Firevox might well 
implement headers association in javascript making it quite 
straightforward to try out different possibilities. Possibly other AT 
allows user scripts that could do the needed job.

Of course this isn't the only way to effect change; Hixie might decide 
that the arguments presented are stronger than his counter arguments 
when he next examines this issue. But it is by far the most compelling 
and potentially gets an implementation into the hands of users which is 
good for them and good for us when we reach CR.

Received on Sunday, 24 August 2008 16:50:52 UTC