Re: summary="" in HTML5

Ian Hickson 2009-02-24 03.54:
> On Tue, 17 Feb 2009, Leif Halvard Silli wrote:
>> Following Ian's advice to give feedback in the form "as defined, I can't 
>> do this with HTML5"[3]:
>>
>> Both <caption> and @summary provide metadata. But currently, in HTML 5, 
>> one cannot author the table metadata with both screen readers and visual 
>> media in mind, simply because, in visual medias, a long and wordy 
>> caption would not work or serve its purpose as caption. Such <caption>s 
>> would not even work for screen readers, since those readers too need 
>> short, clue giving captions. (As soon as one learns what a particular 
>> table is about, the @summary looses more if its purpose, while the short 
>> <caption> increases its usefullness.)
> 
> I am concerned here over the media-specific aspect of this problem 
> statement. What about other media, such as braille? If something is 
> media-specific, then it should be handled by the styling layer. Much as 

Yes, should be handled by a styling layer. At least in theory.

> how people hide links to skip navigation from the visual rendering when it 
> only applies to screen readers, navigation information that the author 
> thinks would only apply to users of screen readers should be hidden from 
> other media. (Screen readers properly supporting the 'speech' media would 
> significantly aid in making pages written by caring authors more 
> accessible, since hacks like 'text-indent' would not be needed.)
> 
> Looking past the media-specific nature of this argument, I don't actually 
> understand what is being described. It appears that what is being stated 
> is that long captions are problematic in all media (much like any long 
> prose, it would seem to me), and furthermore that with a caption, a 
> summary is less useful (which makes sense as far as I can tell).

I'm sorry to not have explained this well enough.

Explanation: One only needs to read the table instruction as long 
as one is unfamilar with the table. Once one is familar with the 
table (because one has gone through it in all directions oneself) 
one will not be so interested the overview anymore.

So, it is not that the caption becomes more important, perhaps, 
but the summary that becomes less important. (It could als also be 
the opposite though: As you becomes familiar with the table, you 
understand the overview better.)

This is also one reason that one needs to distinguish captioning 
content from summarising content. One must be able to know what 
one refers to.

>> Thus, HTML 5 as defined does not let us provide users with fast accessed 
>> and fast read summaries of tables for the situations when the <caption> 
>> does not give the reader enough clue about what the table is about, when 
>> starting to wade through the table itself to find this out, would be 
>> considerably more timeconsuming than reading a such description.
> 
> If the caption doesn't help the user, why would summary=""?

Because a <caption> is a table title. ANd at table title can e.g. 
be only "Table 10: Outcome of the first test." This is very little 
"to become wise frome". A summary can explain that "First test was 
about this and that. That is listed there. And this is listed 
there." This info is fast read. And if the user e.g. reread the 
text, he/she will perhaps remember what the table was about simply 
by reading that text. As Joshue told, screen readers might jump 
from table to table, and then need some context regarding what the 
table is about. As single cells can be rather naked in contenct, 
one would need to criss-cross the table to get an overview, wheras 
summary could give that instantly.

> How is summary="" supposed to be exposed to users of visual browsers? 
> After all, it's not just users who don't have a screen who need to 
> understand complex tables. Wouldn't it be better for the information to be 
> available to everyone? (Isn't that the whole point of accessibility?)

There could be advantages to both. Let's consider the advantage of 
only targeting the unsighted usergroup: It has been argued that we 
don't need fallback for video, because the point of video is the 
video. Without going into that question too much, I also think 
that just as video is best created if one take into account those 
that can actualy see the video, a summary text with the purpose of 
helping non-sighted is also best made if one make with only that 
target group in mind. So this is the positive side of having an 
attribute that only has one usergroup in mind.

But I am not certain that this advantage so enormous that it would 
be wise to avoid an element or attribute that could help all 
users. Probably not.

>> HTML 5, as defined, also does not ofer any way for providing any such 
>> table spesific metatada *without* also adding a <caption>. (Authors may 
>> feel that not all tables *needs* a any <caption>. However, non-visual 
>> media users could benefit from a summary function even in those cases.) 
>> Strictly speaking, a summary feature could be useful for all media 
>> types, if there were a cross-media method for providing it. Perhaps as a 
>> <summary> child element of <caption>? However, then one would need tom 
>> make <caption> a required element.
> 
> This assums that there is a need for tables to have both captions and 
> summaries, which is unclear to me.

Below yo propose to joine sumary and caption into one element. I 
guess this is what you mean here. (THus you agree that wee need 
both, but it isn't clear to you that we need to keep them separate.)

Yes, I am quite certain that AT software needs to distinguish the 
one from the other. And so does in fact all UAs. (In the example 
you give in the draft, the "real" caption has now become "Table 
Number" inside <strong>.)


> On Wed, 18 Feb 2009, Leif Halvard Silli wrote:
>> This message investigate the option of replacing table@summary with 
>> caption@title.
> 
> That doesn't really seem to change anything, does it? Why would the latter 
> be better than the former?
> 
> 
>>    * Avoids the problems of the (claimed) misused @summary
> 
> How so? Surely it would just move the problems from one attribute to 
> another.

Because it would be like starting from a clean slate and so on. (I 
feel like I allready explained this point.)


> On Sat, 21 Feb 2009, Leif Halvard Silli wrote:
>> What HTML 5 says about <caption> is, in my view, not enough, regardless. 
>> HTML 5 should recognise the problem that @summary is supposed to solve 
>> and prescribe ways to solve it.
> 
> I've added text to address this.

The example  you have made there is telling:

<table>
<caption><strong>Table 1.</strong> This table shows the total 
score obtained from rolling two six-sided dice. The first row 
represents the value of the first die, the first column the value 
of the second die. The total is given in the cell that corresponds 
to the values of the two dice.</caption>
   1  2  3  4  5  6
1  2  3  4  5  6  7
2  3  4  5  6  7  8
3  4  5  6  7  8  9
4  5  6  7  8  9  10
5  6  7  8  9  10  11
6  7  8  9  10  11  12
</table>

It would be possible to claim that such a long caption no longer 
is a caption, would it not?  I think this could create problems. 
This not longer is pure table title. E.g. AT needs title to 
navigate between elements.

If you are effectively concatenating @summary and <caption>, then 
why not define a way to subdivide caption? Caption as you have 
defined it here, becomes more like the <header> element, with a 
"title segment" first (<strong>Table 1</strong> in your example in 
the draft). As such, it could make sence to divide it in a summary 
section and a caption section.

Currently screen readers discern between caption and heading. E.g. 
Jaws tells some general table info between the caption and the 
summary, thus distinguishing the one element from the other. Like 
you propose it here, it all come in one big chunk, I'm afraid.

>> It is when one has allread used <caption> for something else, or when 
>> the summary info is longer than what is fit for a caption, that one 
>> really needs @summary.
> 
> Could you give an example of this from a real Web page? Is this common 
> enough that it matters enough that we should handle it? (How often are 
> they used together today?)

This depends on what you mean. The Vegetarian newsletter in 
collection of tables that Steve came up with did have both - as I 
have allready explained. But the problem was that the author did 
not use a real <caption> but instead a table cell as caption. 
However, that table had both. The caption was short, as one 
expects captions to be.

If everything is going in one element, then I'm sure authors want 
to subdivide.
 
[...]

> The conclusion I draw from this data is that summary="" hurts users who 
> don't have access to it, hiding information that they could use, hurts 
> users who DO have access to it, encouraging people to consider layout 
> tables acceptable; and hurts the authors writing these tables, wasting 
> their time writing summaries when their time would be better spent making 
> pages accessible to _everyone_.

As long as one cannot split <caption> in a title part and an about 
part, I'm afraid that we will encourage authors to wwrite short 
title-like captions, and thus perhaps hamper accessibility for AT 
users. (Because unless they keep it short, they cannot get it to 
function like they want - as a caption.) Plus the before mentioned 
need for AT to distinguish between title and "about text".

> It's worth noting again that this data is representative of the very best 
> that we can expect from Web authors.
> 
> I think this answers all three questions posed above (1, 2, and 3 
> regarding how to evaluate solutions). The summary="" attribute fails to 
> improve accessibility in practice, despite being promising in theory. It 
> does cause some users to get a suboptimal experience (sometimes the AT 
> user, via bogus data, others the non-AT user, via missing data).

The "missing data" situation for AT users today might be caused by 
too little focus on <caption>, it could be claimed. I see that point.

> On Fri, 20 Feb 2009, Leif Halvard Silli wrote:
>> Perhaps Ian, Sam or Chris could shed some light on this? Are we doomed 
>> to discuss @summary only? Or can we discuss how tables could be improved 
>> e.g. with new table meta data elements?
> 
> I can't speak for Sam and Chris, but personally I'm looking at the long 
> term, and so I certainly wouldn't limit us to discussing summary="" only. 
> We should investigate any and all solutions that would help users (all 
> users) understand the Web better.

Hence, your opinion about a way to designate a part of the caption 
as "title", please.

>> As long as <caption> is strictly intended as a <table> title, there is 
>> need for another place to place other metadata that is directly linked 
>> to the table. Well, one method is perhaps to place <table>s in <figure>.
> 
> I've clarified that the <caption> is not limited to the title, and 
> included an example of this.

> CONCLUSION:
> 
> Data collected continues to show that summary="" does not provide benefits 
> beyond those that could be provided by <caption>. Indeed, while previous 
> data showed merely that many authors misunderstand summary="" and misuse 
> it to the detriment of AT users, new data (quoted above) shows that 
> authors who _do_ understand summary="", and are compelled (by law!) to use 
> it, end up actually removing information that would be useful to users who 
> don't have access to summary="" attributes!

I cannot guarantee that real AT users and experts agree, but AT 
software does seem to distinguish betwen caption and summary. (And 
I have tested 7-8 AT agents ...) Even when a table has either only 
captin or only summary, it is possible to know whether it is the 
one or the other. Byt not having @summar in the first place, you 
remove this distinction. ANd you provide users with lots of data 
when they only need a title. But if we could at least subdivde 
<caption>, then we could say that the distinction is kept.

Also consider that it is necesary to e.g. create Table of contents 
which refers to the table. Should it then list the entire wordy 
caption? This is not what captions are designated for.

> I have updated the spec to include advice on using the <caption> element 
> to include information regarding how to use the element to benefit all 
> users, including AT users.


Leif halvard silli

Received on Tuesday, 24 February 2009 05:31:20 UTC