Jonas Sicking 2009-02-25 19.42: > Two suggestions I've seen so far are: > > * Use a <p> above the table describing the contents of the table. Just wrap the table in a <figure>. (Not to solve @summary, but to link particular paragraphs to a table.) > * Change the definition of <caption> to not just be the title of the > table to also be allowed to contain a summary. > > Both these have the advantage if adding accessibility to all users > rather than just ones that use AT clients. Neutrally spoken, the two solutions share: - text visibility - semantic unclarity (is this a caption or a summary?) - unspecificity (where does the summary/caption end/begin?) Visibility can help authors do it right by reminding them about features. But if users/authors are unable to *see* that "this is a summary, because it is presented/marked up in a way that differs from the context" then authors do not get any help. Instead we risk a lot of "creativity", without unambigioius user benefits, when authors try to separate summary from caption etc. <header> can contain several H1-H6 and P elements. What if authors were required to collpse <header> into a single string and use a single H1-H6 element instead? So why should we permit <caption> to contain two info-levels without also offering a way to distinguish the two? > Another suggestion I've thought about is using the table@title > attribute. Title attributes are already often used to add descriptive > information out-of-flow. And title attributes are generally available > in visual UAs in the form of tooltips. Our design principle "Separation of Concerns" is also known as "Kill Your Babies". If the choice is betwen @title and @summary, then @summary wins easily. -- leif halvard silliReceived on Thursday, 26 February 2009 03:46:07 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:48:47 GMT