Re: summary="" in HTML5 ISSUE-32

Ian Hickson 2009-02-27 02.40:
> On Fri, 27 Feb 2009, Leif Halvard Silli wrote:
>> Ian Hickson 2009-02-26 12.46:

[ Subject: discerning caption and summary: ]

>> * h1-h6 can be used to creat Table of Contents. If I create a
>> "List of Tables", then I would use <caption> for that.
> 
> This seems academic; I've never actually seen anyone do this
> (unlike tables of contents, which are quite common).

ToC-s are academic things, often. But AT also use them. See below.

> [...] However, I think the problem would be more widespread
> than that, since even without summary="", captions (and legends
> on figures) are still going to include more than just the title
> of the table or work. For instance, sources, artists, 
> publication dates, etc, might all be included in captions and
> legends. So this seems like it would be a more general problem.
> (Maybe the use of <strong> as in the spec example is a place to
> start here.)

Regarding the paranthesis, e.g. replacing  <strong> with <header> 
(wihtout h1-h6 elements allowed inside)?

>> * 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.
> 
> Do we have any data on this? It seems that if authors are
> willing to put information in the summary="", it wouldn't be a
> stretch to have advocacy get them to put the information in the
> caption. It would be useful to have real data on this.

Via the CSS caption-side property the caption can be placed at the 
bottom of the table. Not the typical thing to do if one considers 
the info inside <caption> essential to understand the table?

>> Thus AT software has no certain way to discern between table
>> title and table summary.
> 
> Why would they need any way?

It is my understanding that AT software internaly generate such a
ToC-s of tables.

WCAG 2.0, H39, [1]

"[...] The caption element is the appropriate markup for such text
and it ensures that the table identifier remains associated with
the table, including visually (by default). In addition, using the
caption element allows screen reading software to navigate
directly to the caption for a table if one is present. [...]"

I suspect we will have to raise an issue about <caption> as well
as taking it to the W3 accessibilty experts if you insist on this
unspesific broad use of <caption>.

>>>> E.g. AT needs title to navigate between elements.
>>> Which elements?
>> Between tables.
> 
> I don't understand. Why wouldn't the start of each caption
> handle that fine?

If you think it is supposed to work that way, then why haven't you
written it into the draft? Why did you use <strong> if you think 
it is supposed to work that way?

>> I proposed captioni@title exactly because it would help the
>> author to discern between summary and caption.  Discernig,
>> *that* is the real problem here. You, OTOH, takes the
>> troubles that journal author has with discerning between the
>> two features as proof that we can just clash them together.
> 
> If the author has problem discerning the difference, why bother
> continuing to encourage them to try to discern the difference?

By insisting on making the summary content visible, you are in
principle insisting on the same thing. See below.

The problem *today* is not that the authors have problems with 
discerning, but that they are not *aware* that there is anything 
to discern between.

> There's no point providing more semantic expressive power to
> the author than they are able to use correctly.

This does not speak to the argument.

> It's the equivalent of creating a paint brush that has a brush
> so thin it can paint individual strands of hair, and then
> providing that paint brush to a painter whose dexterity and
> agility is limited to hitting something roughly within an inch
> of where they aim. The painter will never be able to make
> adequate use of such a tiny brush, at least not for the
> intended purpose of fine detail.

What I was trying express was that there is a difference between 
the letter O and the number 0. But that if you place the two near 
each other and tell authors that "these are different", then they 
will be trying to understand the the difference - as well as the 
likeness. The more so if the one is an attribute of the other. 
Unless they are close to eaceh others, hen one will not start to 
compare them though.

(For instance, the author of the Vegetarian journal that we
discussed appeared to not be very aware of <caption> at all. Had
he been, then I'm sure that he would have use only the one or thge
other, an that @summary would had useful content - if any.)

>> 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.
> 
> Making the language more complicated isn't going to help the
> author see the difference. Education might, but we've had
> limited luck with education and outreach on the Web, and so we
> should limit ourselves to where we can get the biggest "bang
> for the buck". I highly doubt that this is one such instance,
> given the trouble authors have with summaries today.

You have pointed to numerous data that show that one mistakes the 
one for the other. And you *do* have a point when you say that the
problem is that @summary isn't visible. But the complication here 
is not oly to separate @summary from <caption>. The bigger problem 
is to see that they are related. It is only when one see that they 
are related that one needs to discern them. Until then, one will 
just place caption in summary - or both places etc.

The real clue in your own obsevervation isn't, IMHO, the mere 
visibility aspect but the fact that if both had been visible
simulatenously, then we would have gotten the same effect that I
was after when I proposed to use caption@title.

Namely: With the two features juxataposed, authors would have 
started to question whether it could be right to use the two for 
the same thing. (And they would have found the answer easier.)

It of course hurts the web when authors are not confronted with
the difference between summary and caption  (because they do not 
see the likenesss in the first place). Or that when they think of 
summary, that they are not confronted with the option of 
<caption>. Or with the option to use both.

>> Here it sounds as if you are indeed open to adding a new
>> element.
> 
> I'm open to any suggestion that actually takes into account the
> realities of the data we have and has a realistic chance of
> achieving the goal of improving accessibility.

Good, I willl make some proposals for this. See below. But first:

The natural conclusion from the data is to say that authors are
not exposed to the problem of irrelevant and duplicate data and
that this hinders them from perceiving their own mistakes.

The main reason for this lack of confrontation is that the two
features, @summary and <caption>, do not appear in same context,
whether when during coding the page *nor* during browsing

Moving the code to the same context (<caption>) would help. As
would it help if authors could test/see the basic aspect of 
summary and caption without AT software.

>> Which parsers is it that are unable to handle a new elment
>> inside <caption>?
> 
> Inside <caption> I don't think there would be any problem with
> adding new elements, I just don't see the need. The parser
> problems are with elements at the level of <caption> (i.e. new
> children of <table>).

Alternative proposals:

1. <caption>Caption.
    <summary>Summary only.</summary></caption>

2. <caption>
    <header>Caption.</header>
            Summary and everything else.</caption>

3. <caption>
    <header>Caption.</header>
            Everything else.
    <summary>Summary.</sumary> </caption>

4. <caption summary="Summary">Caption.</caption>

5. <caption title="Summary">Caption.</caption>


Proposal 2 (<header> wihtout h1-h6 elements) is quite close to the 
current draft. You have allready demonstrated that it is typical 
to be wanting to single out the title part of an caption (whenever 
one fills the caption with summary and other guidance info).  And 
this use of the <header> element could also be transferred to the 
<figure> caption element and thus make it more accesssible. 
However, the <header> should be optional to use for terse <caption>s.

The possible disadvantage to proposal 2 is that it does not
focus on spesific screen reader needs (but it *do* focus on the 
need for captions!). Whenever one has to hide the <caption>  - in 
navigation tables or whatever - one must use caption{height:0} and 
similar.

Another possible disadvantage is whenever the author wants to 
display the <header> for all, but hide the rest of the <caption>. 
(Eventually, for those cases, one could use @summary. Preferrably
@summary on the very <caption> element. Or else I don't think that
understanding will improve.)

I suppose that the *effect* of proposal 2 would be that screen 
readers would treat <header> as they treat <caption> today, and 
the rest of the content as they treat @summary today. This would, 
per the specification (and not only in real life ...) result in 
more diverse content presented as summary. (Which could perhaps be 
a problem. In which case proposal 3 is better .)

Proposal 2 (<summary>) is closest to HTML 4.

Proposal 3 (both <header> and <summary> and additinal content 
inbetween.).

Proposal 4 and 5 (caption@summary, caption@title) are mentioned 
*only* because I think that it really is important to link summary 
to <caption>. If we can't agree on adding either <summary> or 
<header> to <caption>, then we should at least move - or make it 
conforming - to either use <caption title=""> (sorry Joshue) or 
(perhaps rather) <caption summary=""> instead of <table summary="">.

Placing the attribut inside <captino> would make it much more 
simple to also display the summary info for *any* user. Because it 
is for instance much more complicated to make good use use of

     table:before{content:attr(summary)}

than to use

     caption:before{content:attr(summary)}

And the latter is also much less risky if this attribute is 
supposed to be possible to display in any UA anytime.

>>> David wrote:
>>>> 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.
> 
> Insofar as with the proposed spec the information that would
> have been appropriate in summary="" is now in <caption> and is
> now visible, it seems that the summary is indeed now visible.

I can assure you that you disagree with David. "*the* summary" is 
not visible. But *any* summary inside <caption> would of course be 
visible. But it it isn't visible that it is a summary.

>> With your solution it is entirelty up to the author to
>> "invent" a difference betwen what is summary and what is
>> <caption>.
> 
> I'm suggesting there is no need for a difference.

Yet you demonstrate in your example in the draft that there is.

[1] http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H39.html
-- 
leif halvard silli

Received on Friday, 27 February 2009 07:47:52 UTC