Re: retention of summary attribute for TABLE element

Is this issue similar to the headers issue?  Has the summary attribute not 
been
added to the specs yet because further research needs to be done?

Issues that deal with accessibility need to examined more thoroughly before
they are dropped or not added to future specs before they "fall off the 
radar" so to speak.

I agree with Gregory in saying that a mechanism similar <caption> would
be effective for visual and non-visual browsers.

Suggestion:  The summary of a table could display visually (similar to 
<caption>)
either underneath caption text or underneath the table itself as a footnote. 
(But
both of these would have some backward compatibility issues associated with 
them).

In any case, I would suggest that this attribute needs to be looked at 
before being dropped.


-Chris Boudy


> Gregory J. Rosmaita wrote:
>> what justified this decision?
>
> I don't actually know the reasons for not including summary but I would 
> guess they were related to the fact that @summary is tying up important 
> metadata in an invisible attribute. Invisible data is more likely to be 
> missing or incorrect than visible data; according to [1] @summary is 
> present on about 2.5% of tables, I would expect it to be unhelpful on many 
> of those (though clearly some actual research would be needed here. [2] 
> has some results, mostly from CMS templates).
>>  a summary makes it possible for someone processing the TABLE 
>> non-visually or in small highly magnified chunks to get an over-view of 
>> the TABLE, for what is a TABLE, other than a visual means of displaying 
>> related data sets, and what the sighted user sees at a glance -- the 
>> spatial relationships between cells, rows, and column -- but, in the 
>> absence of a summary, the aural user must investigate the table carefully 
>> and fully, just in order to ascertain whether or not it is the correct 
>> table, how many rows by how many columns to expect, etc.
>
> OK, this sounds like a use case for a feature providing an overview of a 
> table's contents. In general I think it's better to work from use cases + 
> backward compatibility requirements rather than HTML4 directly. It seems 
> like some of the problems could be solved automatically e.g. saying how 
> many rows and columns are in the table. Is this not the case? If this can 
> be done, the remaining problem sounds like it could be solved either 
> through <caption> or another mechanism for associating text that is, by 
> default, displayed in visual UAs with the table. Of course I also believe 
> that the behavior of @summary should be specced for UAs.
>
> [1] http://code.google.com/webstats/2005-12/tables.html
> [2] 
> http://www.google.com/codesearch?q=%3Ctable+summary%3D%22&hl=en&btnG=Search+Code
> -- 
> "Instructions to follow very carefully.
> Go to Tesco's.  Go to the coffee aisle.  Look at the instant coffee. 
> Notice that Kenco now comes in refil packs.  Admire the tray on the shelf. 
> It's exquiste corrugated boxiness. The way how it didn't get crushed on 
> its long journey from the factory. Now pick up a refil bag. Admire the 
> antioxidant claim.  Gaze in awe at the environmental claims written on the 
> back of the refil bag.  Start stroking it gently, its my packaging 
> precious, all mine....  Be thankful that Amy has only given you the 
> highlights of the reasons why that bag is so brilliant."
> -- ajs
>
>

Received on Monday, 11 June 2007 15:55:18 UTC