Re: Current state of the summary discussion

Martin Kliehm, Fri, 18 Dec 2009 12:58:10 +0100:
> Martin wrote:
>>> I believe since nobody objects @datetime and <time> in its two 
>>> manifestations, using it as an analogy may help to get the point 
>>> through.
> 
> Leif wrote in reply:
>> It is easier, probably, for an developer to programmatically update 
>> the date than to do the same with @summary.
> 
> My point was that two different methods, an attribute and an element, 
> exist for datetime. Therefore we can have the same for summary.

OK. Good point. Well, my idea was also to have both as valid options.
 
> Your point addresses the *quality* of the summary text. Yes, it's 
> true from a developer standpoint: generated text is more likely to be 
> correct than manually edited text.
> 
> But in all other content we trust writers, why wouldn't we apply the 
> same here? In my experience default summary text is often the result 
> of a missing integration of an editable field in the CMS or missing 
> support in the WYSIWYG editor. Somebody thought of it in the 
> template, but it never made it into the CMS. But when it's visible in 
> the CMS, authors will try to write something meaningful in it.

I would say that if we have a <summary>, then @summary becomes a 
solution for the cases when we cannot use <summary>. I believe that 
<summary>, if it is required to put table help text there instead of 
directly in the <caption>, would create an awareness for the need of a 
table summary, and that this awareness of the issue would lead to 
@summary also being understood and used correctly. A correct and good 
understanding is more important for increasing the use of @summary, 
than anything else. It is not, I think, a goal to increase the use of 
exactly @summary per se, but it is a goal to increase the use of 
programmatically identifiable and useful table summaries. 

> This 
> is also interesting in regard of the visibility discussion: the 
> summary is *always* visible in the CMS.

I did not understand this point.

>> As for <summary> as direct child of <table>, if that was your idea, 
>> then this is just another variant of an invisible @summary
> 
> Oh, I see, backwards compatibility. Yes, I agree <summary> needs to 
> be inserted where current browsers will display the content.

That is one side of it. 

The other important thing is that since Ian suggests that what hitherto 
has been recommended inside @summary  should be placed directly inside 
the <caption> instead, it means that, unless we say that this 
additional text should go into <summary>, then we loose AT's ability to 
programmatically discern between the identifying part of the caption 
and the help text part of the caption. According to the WCAG 2.0 spec, 
it is important that the table summary can programmatically be 
identified.
-- 
leif halvard silli

Received on Friday, 18 December 2009 12:42:45 UTC