Re: summary="" in HTML5 ISSUE-32

Ian Hickson 2009-02-26 12.46:
> On Mon, 23 Feb 2009, William Loughborough wrote:

>> That there is any causal connection between wrong use and ignored 
>> features doesn't seem all that clear.
> 
> Can you give an example of a feature that is widely misused by authors and 
> yet is still activated by users?

@title, probably.

>>> Some of the tables I've seen discussed in this thread are tables for 
>>> which I really wish I had access to real summaries.
>> Well then keep it in the spec.
> 
> Unfortunately summary="" can't be made visible in Web browsers, due to the 
> wide mis-use of the attribute.

As with @title, it can.

[...]

>> 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.)
> 
> Right.
> 
> 
>> Yes, I am quite certain that AT software needs to distinguish the one 
>> from the other. And so does in fact all UAs.
> 
> Why?

For all UAs and all authors:

* h1-h6 can be used to creat Table of Contents. If I create a 
"List of Tables", then I would use <caption> for that.

* discerning between summary and table title shouldn't just be 
possible. It should be *simple*. (See my reply to Jonas [1])

For AT software:

* The fact that many authors probably will want to let the 
<caption> only be a caption, could make them avoid inserting any 
table summary into the same caption.

If you had added a <summary> element, however, then it could work. 
  Or if you had added a <tabletitle> element, which was to be used 
to single out the table-title-part when <caption> containend both 
caption and summary, then I think I could agree.


>> (In the example you give in the draft, the "real" caption has now become 
>> "Table Number" inside <strong>.)
> 
> Why is that a problem?

Because other authors would use another method to single out the 
table title. Thus AT software has no certain way to discern 
between table title and table summary. See  my reply to Jonas [1].

Your comment to caption@title:

> If we just use a new attribute and hope for the best, we're not learning 
> from our collective mistakes.

There were many things in the caption@title idea that tried to 
learn from our collective mistakes. One of the most important 
features was that it created a link - but still a difference - 
between caption and summary. This is what fails in your proposal.


>> 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?
> 
> The caption includes more than just the table number, if that's what you 
> mean. But it's not unusual for captions to include lots of information. 
> Consider captions for paintings in museums. They have the title, the 
> media, the artist name, even sometimes backstory and commentary.

So why do you not propose to structure <caption> internally, just 
like <headers>, for instance? <headers> is a result of the need to 
create structured headings, or the need to link some relevant 
stuff to a heading. But still, the draft defines which of the 
elements inside <header> that si the "real" header, namly the 
h1-h6 element of highest rank.


>> I think this could create problems.
> 
> Why?
> 
> 
>> This not longer is pure table title. 
> 
> Why does that matter?

About the <header> element, the draft says:

"For the purposes of document summaries, outlines, and the like, 
the text of header elements is defined to be the text of the 
highest ranked h1–h6 element descendant of the header element,"

And for much of the same reaons, we need to subdivide <caption> if 
we want to allow stuff there that isn't strictly caption stuff.

>> E.g. AT needs title to navigate between elements.
> 
> Which elements?

Between tables.

>> 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.
> 
> What's the use case?

I described this above.

>> 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.
> 
> I don't understand why this is a problem.

I have described why it is a problem above and earlier.


>>>> 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.
> 
> ( http://www.vrg.org/journal/vj2006issue2/vj2006issue2mealplans.htm )

>> 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.
> 
> That page is a great example; 

No it is not. Because: I must admit that this was not a good 
example page *for what you asked about*, namely a page that use 
both attributes.

> the summaries are basically just repetitions 
> of the captions in the cases where there are captions. That page would 
> really _benefit_ from advocacy arguing for captions only, as would all 
> its users, both sighted and not.

FWIW I have allready made the same point in debate with Steve. I 
proposed captioni@title exactly because it would help the author 
to discern between summary and caption.  Discernig, *that* is the 
real problem her. You, OTOH, takes the troubles that journal 
author has with discerning between the two features as proof that 
we can just clash them together.

My attitude is to help the author to see the difference. By 
joining the two you do not offer any help to discern between 
anthing. Instead you hide the issue.


> On Tue, 24 Feb 2009, Henri Sivonen wrote:

>> Given that non-blind Web authors (i.e. most authors) usually don't use a 
>> speech rendering as their primary Web browsing medium, chances are that 
>> more often than not, dabbling in speech styling wouldn't be very 
>> competent.
> 
> Good point. What's really needed isn't full-on speech media control, but a 
> way to explictly hide content from visual users but not screen readers. A 
> kind of 'display: screen-reader' value.

The default display value for @summary is exactly that. ;-)

> On Tue, 24 Feb 2009, Steven Faulkner wrote:

>>> Whether it would be used correctly is a question we can in fact 
>>> answer, since we have ten years' worth of experience with sites using 
>>> summary="", with ample accessibility advocacy, education, and law (!) 
>>> to support it. I'll discuss this further below.
>> No, we can say that in the samples there was wide variability in its 
>> use, whether its used strictly "correctly" is not the issue, is it used 
>> in a way that helps or hinders those that that it is aimed at helping is 
>> a better question, one that you have not answered.
> 
> I think it is clear from the data that summary _at best_ provides no more 
> use to AT users than a <caption> with the same information would, and at 
> worst, irritates users to the point where they stop using the feature.

For this statement to be true, AT software would have to treat 
@summary and captoin the same way. But this isn't the case. They 
are treated differently.

> On Tue, 24 Feb 2009, David Poehlman wrote:
>> One thing we need to do is make summary for data tables visible 
>> regardless of what html 4 says.
> 
> As far as I can tell, the only way we can do that is to use <caption>. Due 
> to complexities with the parser, adding a new element is unlikely to be 
> possile in the near term. Due to the high proportion of useless summary="" 
> values in existing content, we can't expose summary="". <caption> already 
> exists and is visible.

Her it sounds as if you are indeed open to adding a new element.

Which parsers is it that are unable to handle a new elment inside 
<caption>?


>> Why?  because as has been stated, it aids with the cognative load in 
>> many instances and something perhaps not thought of if I am using screen 
>> mag software, I might not be able to get the entire table in view at 
>> once thereby breaking my view of it so the summary would help me to pick 
>> out the interesting bits.  Also, making summary visible might encourage 
>> authors to get it right.
> 
> Agreed entirely.

You did not get David's point.

You are not making summary visible. With your solution it is 
entirelty up to the author to "invent" a difference betwen what is 
summary and what is <caption>.

If you want to make the difference visible, as Davide proposed, 
then you must come up with either an attribute or an element which 
we can use to place the summary.


> On Thu, 26 Feb 2009, Steven Faulkner wrote:
>>> That would be ideal, but unfortunately, pages on the Web that use
>>> summary="" almost always use it incorrectly, with horrible values that
>>> aren't helpful to anyone
>> This a statement of opinion not fact. Please do not continue to assert
>> this without providing a balanced study of summary use to back it up.
> 
> There have been a number of such studies. Here's one:
> 
>    http://canvex.lazyilluminati.com/misc/summary.html
> 
> Philip's data has in the past been found to track very closely with the 
> results of my own studies of billions of pages, so I would say the above 
> is representative of what one might expect across any more or less random 
> sample of the Web.
> 
> If one examines this data, one finds that not one of the values found 
> is actually useful. (A few seem like they'd be useful, until you look at 
> the pages, and then you realise that they are redundant with other data 
> immediately before or after the summary.)
> 
> There is no way browser vendors would agree to exposing this data to all 
> users.

It is indeed possible to analyse why there are problems with 
@summary. My thought is that the problem stems from failure to 
*link* summary and caption firstly. The visibility problem is only 
a secondary problem. In fact, there would be little point in 
making summary visible if people did not understand what they were 
seeing.


[1] http://www.w3.org/mid/49A61022.4000607@malform.no
-- 
leif halvard silli

Received on Thursday, 26 February 2009 23:28:16 UTC