Re: Current state of the summary discussion

Laura Carlson, Sat, 19 Dec 2009 04:20:26 -0600:
> On 12/18/09, Ian Hickson <ian@hixie.ch> wrote:
>> On Sat, 19 Dec 2009, Leif Halvard Silli wrote:
>>> Ian Hickson, Sat, 19 Dec 2009 01:29:19 +0000 (UTC):
>>>> 
>>>> What would <summary> do?
>>> 
>>> 1) It would make the table summary programmatically detectable for AT.
>>> According to WCAG 2.0 it is important that the table summary is
>>> programmatically detectable.
>> 
>> Isn't that handled adequately by ARIA?
> 
> That question gets back to the length and ultimately the purpose of
> the summary attribute. Some confusion has existed about both.
> 
> Gez wrote an excellent explanation last June.
> http://juicystudio.com/article/purpose-of-the-summary-attribute.php


[Sorry for long reply ...] 

I liked this outline of @summary in that article:

]]
The purpose of the summary attribute is to define the structure of data 
tables [...] only an author can provide semantic information, such as 
the rows contain the time the bus leaves a particular bus depot, and 
the columns contain the destinations for each journey. [...]
[[

And I wondered: Could a thing such as RDFa been of help here, since it 
is about semantics?

Also: Is it only when the summary is specifically crafted for blind 
that it is necessary to have a programatic determination of it? Can any 
WCAG 2.0 experts answer to this? Gez answers no:

]]
All sides of the debate agree that if a long description is required, 
the long description should be provided to all groups, not just screen 
reader users. The best mechanism to provide a long description is to 
provide a generic description of the table that is available to all 
users, and make the association using WAI-ARIA's aria-describedby 
attribute .
[[

I ask of course because the HTML 5 draft says that summary content can 
be dropped right into <caption>, and I have _not_ observed very many 
protests to that side of Ian's draft. As a result of HTML 5, thus, it 
will be possible to drop these long descriptions that Geez described 
here inside <caption>. And I then wonder: Do Gez or anyone REALLY want 
me to point to a long description _inside_ <caption> via 
@aria-describedby?

Gez' article doesn't make any direct points about the fact that 
@summary allows the table summary to be  "programmatically determined". 
But he points to WCAG 2.0's section on "info and relationships" [1] 
which again has a link to a "Understanding Success Criterion" section 
were it is said: [2]

]]
There may also be cases where it may be a judgment call about what 
information should appear in text and what would need to be directly 
associated, and it may be most appropriate to duplicate some 
information (for instance, in an HTML table, providing the summary both 
in the paragraph before the table and in the summary attribute of the 
table itself). However, wherever possible it is necessary for the 
information to be programmatically determined rather than providing a 
text description before encountering the table. 
[[

* There is no advice here that the table summary can appear _inside 
caption_. 
* But when it says that a table summary could appear in an element 
close to the table, then we can conclude that WCAG 2.0 realizes that an 
element, readable also by the sighted, is an option.
* The reason given for preferring @summary, though, is because it "is 
necessary for the information to be programmatically determined".

Gez article does a good job in narrowing the purpose of @summary: the 
point is not the description length but the description type - a 
description written to provide help especially for those who can't see 
the table. What the need is semantic info.

It is clear that a visible <summary> element cannot take that narrow 
approach, though - it must be possible to read (though not necessarily 
of the same use) for all user groups. Even if it could be possible use 
CSS to hide it - or parts of it - for certain media.

A <summary> inside <caption> would be possible to programmatically 
determine. Thus users would be able to jump right to it or have it 
read. Or jump over it. Of course @aria-describedby allows authors to 
link to that paragraph /before/ the table. This would make it possible 
to programatically determine also a text outside the <table> as a 
description of the table. 

However, that it is possible to link to something outside the <table> 
is not the issue. The issue is that even if HTML 5 permits loads of 
text inside <caption>, what then? Is it necessary that the summary part 
is possible to programmatically determine without further ado? (To have 
to use aria-describedby in order to point to content *inside* the 
<caption> seems just stupid to me.) 

The either-or options:

Either it is a strong enough programatic determination that the table 
help text appears inside the <caption> - and thus inside the <table>. 
Or there is need for more, such a <summary> or @describedby. (A 
<summary> element would be "less" than @describedby, as it is more 
hazzle to use @aria-describedby than to use <summary> -  if you write a 
new table.) And either it is acceptable, without any questions, that 
the earlier "clean" <caption> element now becomes a messy caption + 
userguide element. Or it is not acceptable, and we need (at least) to 
make sure that the help text part is not mixed with the caption part.

Since HTML 5 now permits summary like text inside <caption>, and if 
HTML 5's AT experts find that it is OK put it there, then - provided 
that HTML 5 still would permit the use of @summary - it becomes a 
little gloomy to me when to advice that authors could use @summary.

If we already have <summary>, then I would argue that it would become 
easier to explain @summary. I myself would then try something like this:

"A complex table should have summary which explains how it works for 
those that are unfamiliar to the table including those who can't take 
it in visually. The ideal thing is to place the table overview inside  
<summary> inside <caption>, though you may also use aria-describedby. 
If for whatever reason you are prevented from adding or editing any 
stuff in the <caption> - including if you find that blind users need 
more detailed, semantic info about the table rows and columns than is 
otherwise fitting, then you can use @summary, which is a meant exactly 
for this purpose."

[1] 
http://www.w3.org/TR/2008/REC-WCAG20-20081211/#content-structure-separation-programmatic

[2] 
http://www.w3.org/WAI/WCAG20/quickref/#qr-content-structure-separation-programmatic

-- 
leif halvard silli

Received on Sunday, 20 December 2009 05:34:06 UTC