- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Fri, 15 Jan 2010 21:52:28 +0100
- To: tantek@cs.stanford.edu
- Cc: John Foliot <jfoliot@stanford.edu>, public-html-a11y@w3.org, public-html@w3.org
Tantek Celik, Thu, 14 Jan 2010 20:06:39 +0000: [...] I agree that @summary has a problem that it shares with other invisible/derived data that one has to manually add/update for human consumption. > Or one can learn from those lessons, and: > > 1. Stop creating any new invisible/hidden/dark data > formats/features/patterns which we know would be doomed to eventually > contain rotten/dead content. > > 2. Obsolete or better yet drop altogether existing > invisible/hidden/dark data formats/features/patterns and recommend > use of visible data formats/features/patterns instead. I'll just repeat [1] that WCAG requires that the table summary should be possible to "programatically determine" (as a table summary) for AT. Saying, as the HTML5 language spec draft says, that you can just type the summary inside <caption>, does not make the table summary possible to programmatically determine for AT. And I don't think I will call it to "learn from those lessons" either: The current HTML5 language spec draft claims to have learned two things: That @summary is a failure _and_ that table summaries do not need to be possible to programmatically determine. For the <figure> element, there has been a proposal about a caption attribute - applying that attribute to any element, would make that element a caption. I don't want to evaluate @caption here and now. But a similar approach should be possible for making any element a table summary as well. This would make it possible to programmatically determine the table summary - such as WCAG 2.0 asks for. [1] http://www.w3.org/mid/20100108025355728726.d23e8541@xn--mlform-iua.no -- leif halvard silli
Received on Friday, 15 January 2010 20:53:07 UTC