W3C home > Mailing lists > Public > public-html@w3.org > September 2008

Re: function and impacts (was: @scope and @headers reform)

From: Henri Sivonen <hsivonen@iki.fi>
Date: Thu, 25 Sep 2008 11:24:36 +0300
Cc: Laura Carlson <laura.lee.carlson@gmail.com>, James Craig <jcraig@apple.com>, Al Gilman <alfred.s.gilman@ieee.org>, Chris Wilson <Chris.Wilson@microsoft.com>, W3C WAI-XTECH <wai-xtech@w3.org>, public-html@w3.org, Gez Lemon <gez.lemon@gmail.com>
Message-Id: <B60329DF-EF96-4927-BB8E-06C53BB87D17@iki.fi>
To: joshue.oconnor@cfit.ie

On Sep 25, 2008, at 10:58, Joshue O Connor wrote:

> Henri said:
>> That said, I have four problems with the way headers/id has been  
>> lobbied.
>> 1) Headers pointing to td. I may be missing some practical issues  
>> here, but to me it seems that this is essentially a statement  
>> against native markup semantics enabling accessibility and for  
>> promoting bolt-on accessibility as an ongoing solution.
> It's not a desired stance /against/ native enabling semantics at  
> all. It's a distilled realization that this may be needed in order  
> to make more complex tables accessible in a way that will  
> practically work. Again, the semantic ideal vs the real world.  
> Supporting this behavior in the spec until UAs can deal with the  
> improved algorithm (and you make very valid points about the need to  
> improve it) would mean that HTML 5 will support older AT "out of the  
> box". On this issue anyway.

Why is making headers to point to td relevant to supporting legacy  
UAs? (See my previous email for an elaboration.)

>> 2) The attitude that a *handful* of AT vendors can't implement  
>> complex algorithms so instead it's OK that *countless* authors  
>> should go through trouble they wouldn't need to go through
> >if the client software had the kind of algorithms James' inspector  
> has is just wrong.
> James' table inspector is a very useful tool and yes, AT support for  
> these algorithms is poor. If we try and shoe in our ideal of how  
> things should be, even though we know in the real world our ideals  
> may not be supported, surly we are asking for trouble? Especially  
> when we can see that even existing table algorithms are poorly  
> supported by current AT, and the HTML 4 spec has been a TR for many  
> years. If this pattern continues, and I see little evidence to the  
> contrary, whatever comes out of the stable door when HTML5 is  
> unleashed will in all likelihood also be poorly implemented.

I don't, either, expect AT implement algorithms that HTML5 stipulates.  
However, it seems that the browser side of reporting things to  
accessibility APIs is an area of active development for the top 4  
browser engines.

>> 4) The message has been "HTML5 should have headers/id"--just that.  
>> However, I haven't noticed suggested solutions to obvious problems  
>> that would flow from having headers/id, such as how to deal with  
>> cyclic references.
> Well, we have anecdotal evidence, expert opinion, we could have  
> video footage (though I am unconvinced at how effective that would  
> be), complex table examples to indicate the issue, and many many  
> emails on the pros and cons from a multitude of perspectives. As far  
> as cyclic references, I have never come across them myself, apart  
> from on this list :-)

Here's an example of a table with at least one headers/id cycle:

Regardless of how common this is, if headers cells can be chained AND  
authors can add arbitrary header associations, it is *possible* to  
construct a cyclic header chain. A proper spec must, then, define in  
detail what an agent is to do with cycles. (What does existing client  
software do, btw?)

Henri Sivonen
Received on Thursday, 25 September 2008 08:25:21 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:38 UTC