- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Tue, 26 Aug 2008 15:51:20 -0400
- To: Henri Sivonen <hsivonen@iki.fi>, W3C WAI-XTECH <wai-xtech@w3.org>, HTML WG <public-html@w3.org>
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/ > > >
Received on Tuesday, 26 August 2008 19:52:12 UTC