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

(unknown charset) Re: summarization information delivery options: attribute or element

From: (unknown charset) Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Sat, 27 Feb 2010 17:52:13 +0100
To: (unknown charset) Laura Carlson <laura.lee.carlson@gmail.com>
Cc: (unknown charset) Gez Lemon <g.lemon@webprofession.com>, public-html-a11y@w3.org
Message-ID: <20100227175213378076.957d6ccc@xn--mlform-iua.no>
Hi Laura and Gez,

Laura Carlson, Sat, 27 Feb 2010 05:22:59 -0600:
> Hi Gez,
>> I disagree with "purpose" in the definition, and believe it's one of
>> the reasons the summary attribute has not been used correctly. The
>> important part of the definition is to provide the structure, as
>> that's what screen reader users are most likely to struggle to
>> understand when encountering a data table without the benefit of
>> seeing it. The HTML 4 definition of summary definitely needs to be
>> improved if it's to stay in HTML5.

@summary definition in HTML4 could be improved? Of course. But 
understanding HTML4 is usually my perspective. If we want to come with 
critique against it, then we must understand it first.

@summary only structure descriptor? Not in HTML4. Not in WCAG20.

	Technique H73 in WCAG 2 0: 
        Example 1: @summary plays the role of a combined 
                   summary and caption. (No <caption> used.)
		Example 2: There is a <caption>.
                   Only the "structure" part of the @summary
                   in Example 1 is present. Though "structure"
                   is definitively *not* an exact description
                   of the content of this @summary.

Should we change WCAG 2.0, in order to have @summary stay in HTML5? I 
agree that @summary should stay in HTML5, but I don't think we do that 
cause a good service by narrowing the purpose of @summary.
	See also <caption> description in HTML4 (emphasize is mine):

]]Visual user agents allow sighted people to quickly grasp the 
  structure of the table from the headings as well as the caption.
  A consequence of this is that captions will *OFTEN* be inadequate
  as a summary of the purpose and structure of the table *FROM THE 

Inline annotation: HTML4 describes the result of the fact that most 
authors perceive their work from the perspective of being sighted. But 
the underlying thought here is clearly that the <caption>, when 
authored with users of non-visuall user agents in mind, *may* serve 
everyone. Quote continues:

]]Authors should *THEREFORE* take care to provide additional
  information summarizing the purpose and structure of the table
  using the summary attribute of the TABLE element. [[

One way to improve HTML4 is to say replace "therefore" with "in these 
cases" - that is: when the <caption> does not provide sufficient 
information for users of non-visual user agents.

> This is the definition in the change proposal "Make the table summary
> attribute valid, not obsolete, and conforming" [1]:

I think it is essential that we agree on how to understand @summary, so 
I offer my comments from that perspective. A common understanding will 
also benefit the change proposal that I myself is working on.

> <quote>
> The summary attribute represents a prose summary of the table's
> structure, primarily for user agents rendering to non-visual media
> such as speech and Braille. The value is text.

The one sided focus on "structure" is not in line with WCAG20 or HTML4.
> The primary purpose of the summary attribute is to provide concise
> guidance to people with vision impairments on how to read a table,
> where the structure and reading order is visually evident, but not
> available to some assistive technology users.


To talk about "guidance on how to read" is a much better than to say 
than "structure" and also more in line with WCAG20, in my view. But I 
do miss the perspective that the @summary can essentially serve as 
"fallback" for the lack of a caption. WCAG20 technique H73 clearly 
shows that it can.

> The summary attribute is
> not intended to provide a long description of a data table.

This is simply confusing to say. You can only consult the WCAG20 
technique H73, and you will see that the summary is much longer than 
the caption. But, OK, I admit that it could be a useful thing to say, 
if you  somewhere would provide a definition of what "long description" 
meant ... And/Or if you described how one eventually *should* provide a 
_long_ description of the table. In other words: We need some context 
to understand what "long" is meant to imply ... I try to take these 
things up in my change proposal.

A better focus would be to say that the purpose of @summary is not the 
length, but to offer such and such kind of description.

> The summary attribute may be set on the table element if the data it
> contains is of sufficient complexity that users of non-visual user
> agents would benefit from a prose description of the table's
> structure.

WCAG20 technique H73 also mentions that it can be useful when the table 
is very long. (I assume, again, that *purpose* comes into play: Is it 
worth digging into the table? And if I do, should I be prepared for a 
very long table? E.g. if you find a table that essentially is the 
telephone directory for London, then you should know that in advance, 
so you are prepared for a long read etc ...)

> If the table contains data considered to only require a
> short description, use the caption element. Do not repeat the content
> of the caption element as content in the summary attribute.

My change proposal includes the option that the <caption> in these 
cases can be hidden for sighted users, if that is what the designer 
wants. (Of course, it ought not be hidden - but it is an option.) I 
would argue that a hidden <caption> would be more accessible than 
@summary is.

> The attribute may only be set on tables that contain tabular data. The
> attribute must not be set on tables used for layout purposes. The
> attribute should not be set to the empty string.

These are the same requirements that <caption> has (or should have).

> Any user agent may provide a mechanism to access the summary attribute
> content. If the mechanism provides the summary content as conditional
> content it must be input device independent.
> The summary DOM attribute must reflect the summary content attribute.
> </quote>
> Ideas for improvement are welcome.

General comment: Ian/HTML5 thinks that <caption> should be allowed to 
contain block elements. I wonder if you have authored your proposal 
from the perspective that <caption> can not contain block elements. My 
change proposal tries to talk about this issue.

> [1] 
leif halvard silli
Received on Saturday, 27 February 2010 16:52:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:09 UTC