

Re: PF Response: @Summary

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 4 Jun 2009 05:19:58 +0000 (UTC)
To: Janina Sajka <janina@rednote.net>
Message-ID: <Pine.LNX.4.62.0906040453480.16244@hixie.dreamhostps.com>
On Wed, 3 Jun 2009, Janina Sajka wrote:
> We request the table summary tag be restored in HTML 5 as per previous 
> communications: 
> http://lists.w3.org/Archives/Public/public-html/2008Aug/0213.html
> Rationale:
> Summary serves a need

Is the need not served by <caption>?

> and serves it well.

that it causes extra harm to users, with certain sites including 
information in the summary="" attribute that should be available to all 
readers universally but that is, due to the use of the summary="" 
attribute, in fact not available universally.

Could you elaborate on why you believe summary="" serves its purpose well?

> It is familiar to users.

find the summary="" attribute to be useful. When you say that the 
attribute is familiar to users, do you mean that they like it? On what do 
you base this assessment?

> It is properly utilized on many web sites which strive to be accessible.

Actually the research I have seen suggests quite the opposite -- that 
sites that strive to be accessible actually use it so incorrectly that 
they reduce the accessibility of the site to users that don't have (or 
need) screen reader software, for example by including important 
information in the summary="" attribute that would be better placed in a 
table caption or elsewhere on the page.

> *	If it didn't exist, we'd need to invent it. Indeed, such alternative
> *	approaches as have been proposed constitute a "reinvention" of
> *	summary. PF wishes to move on to address accessibility concerns in
> *	areas, such as canvas, where no good solution currently exists rather
> *	than reinventing summary.

The summary="" attribute has failed improve accessibility for tables. I do 
not believe we should ignore this. We have a moral imperative to make the 
Web accessible to all users, and this means being honest about what works 
and what does not. The summary="" attribute, according to all the data I 
have seen, does not work. Therefore we are IMHO duty-bound to solve the 
problem that it attempted to address.

HTML5 attempts to solve the problem using the <caption> element. I 
understand that PF may not have the bandwidth to review this proposal, but 
I do not believe that we should let PF's limited resources prevent 
potential progress in the development of accessible HTML.

> *	We reject the argument that summary should be removed from the HTML
> *	specification because it is not implemented on most web sites.

I do not believe this argument has ever been made. I would also reject 
such an argument.

> *     We note
> *	that accessibility is poorly supported on most web sites. The wider
> *	web is not an example of good practice.

Indeed, we should do things that would help address this. The summary="" 
attributes contributes to this problem by encouraging authors to consider 
accessibility to be an extra issue to be dealt with separately rather than 
a fundamental concern to be dealt with at first. Using the <caption> 
element for the purpose of orienting users of tables brings the subject to 
the fore, which I believe has a better chance of addressing this very 
important issue.

> *	We need summary for backward compatibility.

HTML5 supports implementing the summary="" attribute for backwards 
compatibility as currently written.

> *	We note that summary is often used as a technique for accessibility
> *	support where governmental regulations require governmental web sites to be
> *	accessible.

The <caption> element can equally be used as such a technique.

> *     An example is the U.S. Government's Social Security
> *	Administration (SSA) pages as SSA conforms to its "Section 508."
> *	mandate:
> 	http://www.usdoj.gov/crt/508/web.php

This very page is in fact a clear demonstration of the very problem that 
summary="" introduces. If you search for the table regarding the 
mathematics department, you will see that the screen-reader content is in 
fact more useful to the reader than the "ordinary" content -- there is 
information in the summary="" attribute that should rightfully be 
accessible to all users. The summary="" attribute actually encourages the 
creation of pages that are less accessible to non-screen-reader users. 
This is especially ironic because it is primarily authors who are 
attempting to be as universally accessible as possible who are afflicted 
by this problem.

Using the <caption> element in the very same example would result in 
content that is accessible to all.


To quote from this document:

| Although highly recommended by some webpage designers as a way of 
| summarizing the contents of a table, the "summary" attribute of the 
| TABLE tag is not sufficiently supported by major assistive technology 
| manufacturers to warrant recommendation. Therefore, web developers who 
| are interested in summarizing their tables should consider placing their 
| descriptions either adjacent to their tables or in the body of the 
| table, using such tags as the CAPTION tag.

This is in fact exactly what HTML5 says.

> *	If summary is removed, U.S. Government web sites, might find it more
> *	difficult to conform to HTML 5.

As far as I can tell this concern is unfounded; the <caption> attribute is 
in fact encouraged by the very same government (as quoted above) to be 
used exactly as HTML5 recommends in a manner consistent with the goals of 
the summary="" attribute.

> *     We further note that Section 508
> *	regulations apply to U.S. state and local governments, and that
> *	similar accessibility requirements are emerging in Canada, the U.K.,
> *	the E.U., Australia, and elsewhere.

I entirely agree that accessibility is important; the current text in the 
HTML5 specification encouraging the use of <caption> where previous 
specifications encouraged summary="" is in fact intended to increase the 
accessibility of pages.

> *	Restoring summary in HTML 5 would not, in our understanding, negatively
> *	impact HTML 5 in any way.

possible impact to the specification itself.

Received on Thursday, 4 June 2009 05:20:39 GMT
