Re: summary="" in HTML5

I'm revisiting this part of your letter again:

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?

You are hinting that braille doesn't support @summary. Why?

> If something is media-specific, then it should be handled by 
> the styling layer. Much as 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.)

UAs without CSS support still have to implement meaningfull
styling. Henri said: "arguments rooted in CSS being optional for
the visual medium are more principled than practical". [1]

So far we have discussed only two options:

	1. just keep @summary, without any optimisation;
	2. join/collapse @summary with caption;

But if we count CSS in, then we get a third option:

	3. keeping @summary, with some optimisation.

By "optmisation", I have two things in mind:

   A. Define a default stylesheet that makes UAs render
      @summary. See my test case for proof of concept.[1]

	table[summary]:before{
		content:attr(summary);
		display:table-caption; }

   B. Define what layout tables are, so that UAs doesn't
      render @summary for layout tables. (That is: define
      the circumstances that makes @summary rendered.)

COMMENTS:

   A. When this WG started working, the above CSS rule worked only
      in Opera and perhaps Webkit. Today it works in Firefox 3.1
      and IE 8 beta as well. Again, see my test case. [1]

   B. AT user agents allready define what layout tables are.
      In Henri's words again [3]:

> Saying that layout tables a non-conforming doesn't properly 
> pave this cowpath in an accessible way. [...] more useful to 
> define how to distinguish them from tables of actual tabular 
> data.
> 
> Two syntaxes already have been invented for allowing authors 
> flag a table as a layout table: summary="" (the empty string as
>  the value) and role="presentation". Furthermore, JAWS 
> (reportedly) and Gecko (from source code appearances[1]) 
> already have heuristics for guessing if a table is a layout 
> table.
   [...]
> After all, the claimed accessibility harm of layout tables is 
> not there if layout tables aren't presented as tables to AT 
> users.

   C. Advantages to this method:

   a. The most important side of this method is that it takes away
your argument against @summary, as this would make it available to
all users and the visual display (as well as the HTML 5
spesification) would authors conscious about the feature.

   b. The fact that CSS generated content usually isn't possible to
copy, will place @summary on pair with the @title attribute, whose
content also is impossible to copy. This is logical, because
@summary is designated for the similar kinds of advicory content.
It only promotes a better understanding of what @summary is for.

   c. When you looked at Steve's tables you found that @summary
content often was of help to *all* uses. Thus, this way we would
would help users of all media to read the *existing* web better.

   d. It would keep summary and caption content separated. This
would benefit both authors and users, including AT UA users.

   e. As Henri noted [4], styling content for speech browsers is
complicated. A designated attribute ensures that AT user agents
can style the summary as it is best for their users.

   f. Using an attribute secures that the summaries remain pure
text. (Wheras summaries as content inside <caption> could temt
authors to complicate things. Risking to take away the summary
effect, both due to complicated content and problems for UAs in
discerning between the two.)

   g. To define layout-tables would create a common problem 
understanding for both visual UA vendors and AT UA vendors.

   h. Compatibility with existing practise, standards and user agents.

PP: I see in your edits of the draft that you try to define the
<figure> caption and the <table> caption as equivalent elements.
You even say that <table> should not have a <caption> if the it
the main content of a <figure> and if the <figure> itself has a
caption.

But it is just as natural to look at it from the other
perspeective: One could argue that <figure> needs to have a
summary attribute just as <table> has one.

[1] http://www.w3.org/mid/4921DF3F-FAF4-4EA0-B07C-AD8E6A2D8501@iki.fi
[2] http://www.malform.no/html5/summary+css
[3] See note [1] above.
[4] See note [1] above.
-- 
leif halvard silli

Received on Wednesday, 25 February 2009 01:20:20 UTC