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

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:
http://www.usdoj.gov/jmd/fass/afvreport2005.htm

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
hsivonen@iki.fi
http://hsivonen.iki.fi/