Re: table headers - clear description of problem

On 26 Aug 2008, at 11:11 AM, Henri Sivonen wrote:
>  (It seems to me that implementation-wise the right place to put  
> the association algorithm is browser engines that report stuff to  
> AT--not AT itself.)

+1 to that idea

This fits neatly with what Laura said earlier.  Not that the client  
is frozen,
but that there is an orderly process to manage change with continuity  
of service.

<quote
cite="http://lists.w3.org/Archives/Public/wai-xtech/2008Aug/0265.html">
Grandfather it into the spec until it can be demonstrated that the
HTML5 replacement works better and is in service.
</quote>

Al


> On Aug 26, 2008, at 17:29, Laura Carlson wrote:
>> Source:
>> http://lists.w3.org/Archives/Public/wai-xtech/2007Jun/0021.html
> [..]
>> Source:
>> http://esw.w3.org/topic/HTML/ 
>> TableHeadersTestingBug5822#head-4dd98a1e6b2646ef8c2be83dd7b6c93622e25 
>> f4b
>
>
> It seems that the problem description for headers/id is backwards  
> compatibility in case where authors are competent and willing to  
> cater for existing UAs not making good use of <th> semantics.
>
> It appears, though, that if client software is not assumed to be  
> frozen, for the next generation of client software the general  
> approach taken by the spec (not necessarily exactly as written) is  
> better than the headers/id approach, since there less room for  
> author error when tables are edited and less participation from  
> authors required, which should improve overall accessibility of  
> tables on the Web scale. (It seems to me that implementation-wise  
> the right place to put the association algorithm is browser engines  
> that report stuff to AT--not AT itself.)
>
> -- 
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>
>