Re: summary="" in HTML5 ISSUE-32

On Fri, 27 Feb 2009, Leif Halvard Silli wrote:
> 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.

I don't think title="" is anywhere near as widely misused as summary="", 
but I'm certainly eager to see data to the contrary. My own experience 
(anecdotal) looking at random Web pages suggests that title="" is used 
about as correctly as, say, <p>.


> > > > 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.

If Web browsers are willing to expose it, then that would definitely 
change matters. Are they?

Input from browser vendors here would be helpful.


> > > 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.

This seems academic; I've never actually seen anyone do this (unlike 
tables of contents, which are quite common).

If this becomes a problem, though, I agree that it would make sense to 
define some mechanism to distinguish them. 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.)


> * discerning between summary and table title shouldn't just be possible. 
> It should be *simple*.

That's not a reason why it should be possible. :-)


> 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.

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.


> > > (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.

Why would they need any method?


> Thus AT software has no certain way to discern between table title and 
> table summary.

Why would they need any way?


> See my reply to Jonas [1].

This doesn't seem to speak of reasons.


> 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 don't understand why there is a need for structured captions. If there 
is such a need, I agree that the current solution fails to satisfy it. But 
I don't understand why we would think there is a need.


> 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.

But table titles don't appear in document summaries and outlines, and 
lists of tables are rare (possibly nearly non-existent, though I'm sure it 
happens occasionally) on the Web. So the same reason doesn't apply.


> > > 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?


> 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?

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

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.


> 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.


> > 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.

I don't see how the precondition you state is a precondition for the 
conclusion I stated. They seem orthogonal.


> 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.


> 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>).


> > 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.


> 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 27 February 2009 01:40:53 UTC