Re: summarization information delivery options: attribute or element

Charles McCathieNevile, Tue, 02 Mar 2010 20:40:55 +0100:
> On Thu, 25 Feb 2010 23:48:26 +0100, Gez Lemon:
> ...
>> I don't believe that summary should be an element, as it's supposed to
>> be concise overview of the structure for people who are unable to
>> determine the structure visually.
> 
> Agreed. And the simple way to do that is with an attribute. There used to
> be one for adding a summary of a table.

So may be it is wrong that <caption> is an element too? ;-) The right 
way to make sure that a summary element doesn't contain block level 
elements is not require that it doesn't - in the spec. 
 
> I don't think it is so important whether you think it is a long
> description of a table or a concise summary.

+1

> Some authors are better than
> others, and will do a better job of communicating. Some spec writers and
> educators are better than others and will do a better job of communicating
> what the spec is trying to achieve. But I think it will take a fair bit of
> effort to get a consensus around the goal, and I suspect that effort is
> better spent on making and describing and improving real-world examples
> than on trying to get the wording of the spec itself to be perfect - if it
> is more or less good enough, we can focus on the real world.

Did you mean "provide use cases"?

Btw, how does the use case look like that proves that it has to be an 
attribute?

>> If the reason for making it an
>> element is that authors can provide richer markup, then I think we're
>> definitely outside the territory of a concise overview of the
>> structure of a data table, and more into summary being a long
>> description of the table.
> 
> Or many other things.

One purpose of for an element solution is documented in HTML4 and 
WCAG20 H73: Avoid to duplicate content from the caption in the summary. 
If the element is easy to display as part of the caption, then that 
issue will solve itself. And for that reason, an element, such as 
<summary>, as child of <caption> might be better than a element as 
child of <table>?

<caption>Table 1: Earnings
<summary> … description of the table's organization … visible or 
invisible … author decides …</summary>
</caption>

A second purpose for an element solution is that the table summary 
should be programmatically detectable - according to WCAG2. This is 
much simpler to achieve via a dedicated feature, such as @summary or 
<summary>, rather than through @aria-labelledby. Of course, it will 
have to be specified how to use aria-labelledby="" to achieve this 
purpose. But never the less, aria-labelledby will be subject to rotten 
links and duplicate ids etc. 

>> It should just be provided with markup
>> so that everyone has access to it, and referenced with
>> aria-describedby.
> 
> Yes, for the cases Gregory posits that require being element content,
> using aria-describedBy to point to that content (which might be in the
> caption element content, or might be somewhere else) seems like the
> logical approach.

My change proposal tries to take up that issue. 

And my suggestion there is that the 'table summary' concept belongs to 
aria-labelledby rather than to aria-describedby. 

This is because a table summary is supposed to be short, as Gez said. 
And also because, even in HTML4, it is understood that 'table summary' 
/could/ appear inside <caption>. Hence the warning to not repeat the 
<caption> content in the @summary. One cannot, however require that an 
in depth description doesn't repeat anything - I think. I am no expert 
on ARIA, but it seems wrong to place it all on aria-describedby. ARIA 
also has an example were aria-labelledby is used instead of @alt text 
for an image - see my CP.

http://www.w3.org/html/wg/wiki/ChangeProposals/tableSummaryProposal

-- 
leif halvard silli

Received on Tuesday, 2 March 2010 20:15:07 UTC