Re: summarization information delivery options: attribute or element

Shelley Powers, Fri, 26 Feb 2010 13:10:11 -0600:
> Of course, all of this will probably be in the change proposal, so if 
> you want to just tell me to be patient, that's cool too ;-)

LOL. :-) But thanks for a very thoughtful reply! It sounds like I 
should not wait with my proposal until it is 100% ready ... ;-)

So here is an rough change proposal draft (inspired by an evening out 
with some Opera folks here in Oslo tonight - plus all the thoughts I've 
gathered in this and related groups [but I take the full blame myself]):

Change proposal draft to allow (but not
require) @aria-labelledby and/or <caption>
to take the role of @summary.
===

Short version
---
  * @summary remains valid. 
  * alternatively: @aria-labelledby can point to an element (which
    could even be a <caption> element–see below) with the summary.
  * <caption> can be used for summary, in particular if 
    @aria-labelledby points to it.
  * more than one <caption> element is permitted, if it/they are 
    pointed to by aria-labelledby and/or aria-describedby.
  * @aria-labelledby cannot point to anything inside <caption>,
    but it can point to _a_ <caption>.
  * aria-describedby can _not_ be used for summaries (but it
    can be used for long descriptions! If aria-describedby
    points to a <caption>, then it does not count as summary!)
  * remove HTML5's permission of block elements inside <caption>,
    except when <caption> is pointed to via aria-describedby.

Long version
---
1) No table should be allowed without an @alt like description
   The page is invalid without it. Exception: tables with a ARIA
   @role that explains that the table is a layout table.
2) The summary description could be provided in 3 ways:
 A. @summary
 B. @aria-labelledby
    C. a <caption>

   (Note that B. could point to C.)

Justification/Explanation:

A. @summary - it just works, so it should be allowed, for ever.

B. @aria-labelledby - because it can be a very useful alternative and 
can be used in multiple ways.

 Why @aria-labelledby and not aria-describedby? Because I totally buy 
into that part of of what Gez has said: the summary should be rather 
short. (I think the point meant to be made in HTML4 is that "@summary 
is long, when compared to a typical <caption>" - HTML4 does not know 
about Hixie style long <caption>s with block elements inside.)

 Of course, it should also be permitted to place aria-describedby="*" 
inside the <table> tag, when that is warranted. However, using 
aria-describedby should not in any way buy you free from providing a 
*summary* (for which either @summary, @aria-labelledby and/or <caption> 
must be used).

C. <caption> itself. When HTML401 was specified, CSS was in its 
infancy. Today we are able to hide <caption> quite easily. If there are 
so called "business sites" that are afraid from such a thing as an 
extra caption element, then I highly doubt their business. No "business 
site" fails to rely on CSS these days! (At any rate, @summary should 
remain valid - so no problem.)

 So what do I mean by counting <caption> in as a means for providing a 
summary? Two things:

  FIRSTLY: If the table is not meant to have any visible caption, then 
authors can *still* provide a hidden caption. Just hide it via CSS! I 
created a simple example in Live DOM viewer - see footnote. [1] 

 (I'm not certain that the CSS of that example is as screen reader 
compatible as it could be - that must be tested out, of course. But it 
should be relatively simple to find a solution. The Live DOM Viewer 
example has been tested in Opera, Safari, Firefox and IE7. I also 
tested it in Jaws 10. I also tested it in VoiceOver, but VoiceOver is 
like a sighted person: it only reads that what it considers as visible. 
Ultimately though, I found a VoiceOver compatible solution - which I 
can present later on. @summary is *not* VoiceOver compatible - not in 
OSX 10.5 at least.)

  This kind of use of <caption> is totally within the frames of 
<caption> - just see what I quoted about the relationship between 
@summary and <caption> in section "11.2.2 Table Captions: The CAPTION 
element" - in my last e-mail message. [2] Even WCAG 2.0 contains 
examples where the @summary is nothing but a caption! (Because one use 
case for @summary is to fix tables that are lacking a <caption>!)

  SECONDLY: When a table already does have a "normal" <caption>, then a 
second <caption> element is permitted, as a summary container. (And 
even a third, together with aria-describedby, is permitted.) In order 
that this second <caption> element counts as a table summary, however, 
then @aria-labelledby *must* point to that <caption>. (So, unlike what 
I've said previously: no need for role="summary" or anything like that 
- even if I think @role would also be an OK and - in some ways - better 
solution.) Whether this second summary should be hidden or visible, 
would depend entirely on the specific needs of the designer and/or the 
audience etc. 

 Code example:

<table aria-labelledby="summary" aria-labelledby="longdesc">
 <caption>Windows codepages</caption>
 <caption id="summary" class="hidden" >Comparison of encoding 
           support in different versions of MS Windows</caption>
 <caption id="longdesc" class="hidden visible whatever" >
<ul>
 <li>The rows contain portfolios and the columns contain dates</li>
 <li>The date columns are ordered from most recent to oldest</li>
 <li>The portfolios rows are organized alphabetically</li>
 <li>The aggregate data is in the final two columns</li>
</ul>
 </caption>

 Explanation of code example: 

 Only the second <caption> is a summary - because it is pointed to by 
aria-labelledby. John said that he thought that a list could be useful 
for describing a table. [3] But if so, then this should be considered a 
long description, and not a summary. Hence @aria-describedby for that.

NOTES: 

 1. HTML5 says that <caption> may contain block elements. But at least 
when <caption> is used as a summary container, then no block elements 
should be permitted, since summaries are meant to be short.
 2. When the table only contains a single <caption>, then it should not 
be required to use @aria-labelledby for pointing to that <caption> - 
not even if that caption only contains a summary and is hidden.
 3. A consequence of not requiring aria-labelledby when there is only 
one <caption>, is that any <table> with a <caption> would fulfill the 
requirement that I suggested - namely that all data tables should have 
an @alt like description. Exception: see point 6. below.
 4. As part of this proposal, I would like to suggest that <caption> 
should *not* be permitted to contain block elements *unless* it is  
pointed to by aria-describedby. (And note, that if it is pointed to by 
aria-describedby, then it would neither count as a <caption> nor as a 
summary, and so the <table> would be invalid, unless a @summary, a 
"clean" <caption> and/or @aria-labelledby was added to the table.)
 5. Details: <details> can not be used inside the normal caption, 
because this change proposal turns <caption> into a "pure" caption in 
the HTML4 sense, whereas <details> is a block element. It can also not 
be kept inside the "summary caption" - pointed to via aria-labelledby. 
But it could live inside a caption which is pointed to via 
aria-describedby. When <details> is kept outside the table, then there 
are no limits on how it can be pointed to (but that is a general 
problem of ARIA - there is nothing that technically hinders that 
aria-labelledby points to something - such as a very long text - that 
just can't be considered a label). 
 6. A consequence of 5. is that you _can_ have just *one* <caption> 
element, containing block contents, including <details>, _provided_ 
that you also have a @summary or that @aria-labelledby points to an 
element outside the <table>.
 7. It should not be legal for aria-labelledby to point to a table cell 
- or to some child element of caption (perhaps with the exception that 
<caption> contains nothing but whitespace outside the child element.) 
[Perhaps this is a point of view where the ARIA experts disagree with 
me?]

POSITIVE ISSUES:

- Builds on HTML4 and WCAG in drawing a link between caption and 
summary. 
- Builds on things authors already know about: <caption> and @summary
- Builds on the new goodness: ARIA-labelledby
- Operates with a clear distinction between aria-labelledby and 
aria-describedby. (It seems like many are very hooked up with the 
"describedby" in aria-describedby - "described" is perhaps a simpler 
concept than "labelled"?)

NEGATIVE ISSUES:

- It can be a challenge to make a second or a third caption _visible_ - 
it is difficult to get to work cross browser. My test page from june 
2009 [4] shows that there are challenges, but also that it is possible. 
Of course, user agents must be developed to support this better. 
However, to begin with, then I think it is actually perhaps more 
important that a second caption is easy to make *in*visible.
- Some will probably claim that allowing <caption> to contain a 
summary, can be confusing. To which I will say that both HTML4 and WCAG 
demonstrate that @summary can also be used to repair the lack of a 
caption. So why not repair that lack, with a caption instead?

[1] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/387

[2] http://lists.w3.org/Archives/Public/public-html-a11y/2010Feb/0610

[3] http://lists.w3.org/Archives/Public/public-html-a11y/2010Feb/0608

[4] http://målform.no/html5/caption+role

-- 
leif halvard silli

Received on Saturday, 27 February 2010 07:27:48 UTC