W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: Use and abuse of @summary

From: Michael Cooper <cooper@w3.org>
Date: Mon, 23 Feb 2009 18:01:41 -0500
Message-ID: <49A32AD5.9060305@w3.org>
To: "Patrick H. Lauke" <redux@splintered.co.uk>
CC: HTML WG <public-html@w3.org>, W3C WAI Protocols & Formats <w3c-wai-pf@w3.org>, wai-liaison@w3.org
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

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

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.


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 Monday, 23 February 2009 23:02:27 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:42 UTC