Re: Use and abuse of @summary

Hi Michael,

Regarding H73, the head title there talks about @summary for "to 
give an overview of data tables". But as soon as the body text of 
H73 begins, "overview" is specified to mean "overview of **how 
data has been organized** into a table or a **brief explanation of 
how to navigate** the table".

But in my view an table overview need not be whether be about 
organisation or navigation, it could simply be a note about what 
the table is about, to help the user to decide whether it is 
worther interrogating it. Wheras H73 OTOH, focuses on @summary as 
a "Table how-to". "How to understand this table".

In the discussions of this list, focus on @summary as a method for 
getting a glimpse of what the table is about seems to have had 
much focus. The way H73 describes it, though, @summary is more 
distinct from <caption>. That is the advantage of H73. And also, 
H73 presupposes that <caption> and surrounding text has been used 
to tell what the particular <table> is about, you could say.

Thus, H73 and Patrick in oner way agree, since H73 has this very 
strict understanding of what @summary is for. A strict 
understanding should lead to less use.  Where they disagree are in 
the understanding of how useful the kind of overview that H73 
advices about, are. Patrick also see other uses. (But it seems 
Patrick is in doubt about the usefulness of summary, in general. )

Our task is not H73 but  whether to reinstate @summary or not.  So 
the first  thing we need to answer is whether @summary - or in 
general - table summaries, such as those that one can create with 
@summary, plays any role, and whether they play a unique role, 
whether that role is useful, and how it is useful.

And that I regard, I conclude that

1. The way AT software works,  @summary plays a role. There seems 
to be tables which are designed taking the effects of @summary in 
AT software into account. @summary for data tables gives the user 
are brief overview over the table. The way @summary is authored 
with the effect of AT software in mind, is certainly a thing that 
makes it unique. This "overview effect", directly linked to the 
table, can at present only be created with @summary. (Or else one 
must write long captions - and that was not the purpose of it. And 
even then, as my AT test showed, @summary is "rendered" somewhat 
differently from the caption, in the AT software.) This "effect" 
side of @summary is not linked to whether @summary focus on 
organisation/navigation or on "glimpse of the table". (Perhaps the 
"effect side" is somewhat more geard towards "glimpse" than 
"instruction about how to use the table", though? Or how many 
users are preparted to take instructions as soon as they meet a 
table?)

2. One advantage – sometimes – of the @summary, is that it is 
hidden for visual user agents. This can certainly be both good and 
bad, but sometimes it is definitely good - or practical - that on 
can give specific "overview text" to the non-visual UA users 
without disturbing the over all visual design. It is an advantage 
to not have deal with CSS in order to do the hiding. Summary is 
unique in that it doesn't even becomes visible in text browsers. 
(Lynx does at least not show it by default.) So in one view it is 
the attribute that is the most geared towards non-visual User 
Agent users. This advantage becomes the more important the more 
specific to non-sighted the @summary is written.

3. Going back to point 1 above, it seems to me that @summary gives 
an opportunity to "color" the table presentation for users of 
non-visual UAs. So we could define this as one of the effects of 
@summary. It would be wrong to takeway something that have a 
positive effect. Why should we do that? OTOH, we cannot prescribe 
that authors "color" their texts.

4. Wheras what H73 describes, is what should be "prescribed". Such 
overviews cand indeed  be useful. Authors will disagree about how 
often they are useful, but they all agree that for some tables "in 
the wild", such "how to read this table" overviews are useful and 
needed.

So may be H73 is allright, but that there should be an article 
that described how to use summary to "color texts".

My 2 cents ...

Leif Halvard Silli



Michael Cooper 2009-02-24 00.01:
> I'm responding to this message with my WCAG hat on.
> 
> There have been several formal opportunities for public feedback on WCAG 
> Techniques over the past year. The WCAG WG generally considers and 
> responds to comments received outside of formal comment windows as well. 
> Although WCAG 2.0 is now a W3C Recommendation, Understanding WCAG 2.0 
> and Techniques for WCAG 2.0 are expected to be updated from time to 
> time, so it is still appropriate to comment on them.
> 
> To comment on these documents, please go to 
> http://www.w3.org/WAI/WCAG20/comments/.
> 
> We would prefer that comments be sent to the WCAG WG only after this 
> discussion achieves resolution. We also request that the PFWG coordinate 
> with the WCAG WG in its proposals, to ensure that the final proposal 
> does in fact support conformance to WCAG 2.0. At this point, the WCAG WG 
> is unable to ascertain whether the discussion in this thread of WCAG 
> technique H73 is reflects an error in the technique, a misunderstanding 
> of the technique, an alternate approach for which an additional 
> technique might be helpful, etc. With my PF hat on, I have initiated 
> some of the coordination requested above, but more remains to be done in 
> that.
> 
> Also, it is true that WCAG techniques are advisory - there is no 
> requirement to follow them and there can be good reasons not to follow 
> them. However, they have been carefully considered and should be 
> considered important sources of interpretive guidance for WCAG 2.0. 
> While you may want to take the techniques with a grain of salt, please 
> do not dismiss them out of hand.
> 
> Michael
> 
> Patrick H. Lauke wrote:
>> On Mon, Feb 23, 2009 at 12:45 PM, James Graham <jgraham@opera.com> wrote:
>>
>>   
>>> Patrick H. Lauke wrote:
>>>     
>>>> Worth noting that WCAG 2 techniques are advisory, rather than
>>>> mandatory. Personally, I disagree with this technique's particular
>>>> suggested use of summary for simple tables...and, as it's only
>>>> advisory, that's fine...as long as i and my users are happy that the
>>>> actual mandatory SC 1.3.1 is satisfied.
>>>>       
>>> It's not really fine because WCAG techniques are supposed to be helpful. If
>>> this technique is suggesting something that is widely held to be bad
>>> practice then it should be updated to describe what good practice actually
>>> is.
>>>     
>>
>> Of course the WCAG technique should be changed. The problem is that,
>> unless I missed it, the techniques doc hasn't been up for review
>> (though I assume any feedback sent to the appropriate list would be
>> enough to trigger that conversation). Also, there will be disagreement
>> even among users (of AT in particular) and experts about what *they*
>> prefer...so for each voice saying that the technique isn't valuable
>> there'll be another saying that in fact it is - hence the advisory,
>> informative nature of the techniques.
>>
>>   
>>> For example it is unclear that @summary will be needed to satisfy 1.3.1 at
>>> all since information about the structure of the data is available through
>>> the table cell-headers relationships hence satisfying the "relationships
>>> [...] can be programmatically determined" part of the clause.
>>>     
>>
>> Yup, that's my interpretation as well - unless the structure really
>> does require further explanation because it's so complex and/or
>> non-obvious, at which point I'd posit that the problem is more with
>> the table itself and it presenting too much data. Don't get me wrong,
>> I would want authors to be able to use @summary in that way if they
>> feel that it's needed...but wouldn't say that that's the only valid
>> use for it.
>>
>> P
>>   
> 
> -- 
> 
> Michael Cooper
> Web Accessibility Specialist
> World Wide Web Consortium, Web Accessibility Initiative
> E-mail cooper@w3.org <mailto:cooper@w3.org>
> Information Page <http://www.w3.org/People/cooper/>
>

Received on Tuesday, 24 February 2009 03:41:01 UTC