RE: layout tables

A comprehensive solution but doesn't this run the risk of overloading users
with too much info about the structure of layout tables? Given that
developers will still continue to use tables for layout and that they may
not always linearise correctly would not a better solution be to use
summary="layout table" and then use <title> for each cell that has
meaningful content. If a td has no content (except spacer images etc) then
the lack of a title would be useful and other cells would have, for example,
<td title="navigation cell"> or <td title="content cell">. This has the
bonus of the purpose of each cell becoming apparent when the user hits them
rather than havnig to try and commit the structure of the page to memory.

Julian



> -----Original Message-----
> From: Jukka Korpela [mailto:jukka.korpela@tieke.fi]
> Sent: Friday, November 08, 2002 7:49 AM
> To: wai
> Subject: RE: layout tables
> 
> 
> 
> Kerstin Goldsmith wrote:
> 
> > Has anyone come up with a way to standardize on signaling 
> that a table
> > is being used for layout purposes only?
> 
> This is very good question. It has been discussed to some 
> extent, with no
> apparent consensus, and different practices exist, and 
> different guides and
> programs give different recommendations. So the situation 
> really calls for
> some clear statement. I wonder if there's any mechanism for 
> W3C WAI to take
> an official position, to give an official interpretation of 
> the Guidelines.
> 
> The Guidelines say (checkpoint 5.5): "Provide summaries for tables.
> [Priority 3]  For example, in HTML, use the "summary" 
> attribute of the TABLE
> element." Note that it does not say "for all tables". 
> However, the related
> HTML techniques document describes, at
> http://www.w3.org/TR/WCAG10-HTML-TECHS/#table-summary-info
> the summary attribute in a manner that suggests that it's 
> intended to be
> used for all tables. But no example is given about a summary 
> for a layout
> table.
> 
> > When we run our documentation through our accessibility checking
> > utility, we have told folks to add a null SUMMARY attribute to their
> > tables, and our checking utility recognizes this as a signal that
> > the table need not be checked for association between headers and
> > cells, or for header markup itself.
> 
> This sounds trickish, though I see the practical point.
> 
> > It seems that the SUMMARY=""
> > makes sense in the same way that null ALT attributes work for 
> > decorative graphics, no?
> 
> That's a natural way of looking at it, but maybe not quite 
> correct. For an
> IMG element, the ALT attribute by definition gives the 
> textual alternative
> to be used in place of the image, when the image is not 
> displayed. Thus,
> alt="" says that the adequate textual replacement for the 
> image (when the
> image is not shown) is an empty string. And this is of course 
> quite correct
> for a purely decorative graphic (unless the graphic itself is being
> discussed, of course). For a TABLE element, the SUMMARY 
> attribute is defined
> (according to HTML specifications) as follows: "This 
> attribute provides a
> summary of the table's purpose and structure for user agents 
> rendering to
> non-visual media such as speech and Braille."
> 
> The definition is a bit one-sided, since such a summary could 
> be useful even
> when the table is presented visually. The user might have cognitive
> difficulties in just seeing the structure, or the canvas 
> might be too narrow
> for the table without (horizontal) scrolling, so that it's 
> difficult to get
> a good picture of it as a whole. So it's useful if a graphic 
> browser gives
> the user an optional access to the summary (as Mozilla does: 
> right click on
> the table and select Properties).
> 
> On the other hand, it's _double_ sided: the summary is 
> supposed to describe
> the purpose _and_ structure. The examples in W3C documents 
> add a third job
> to that: describing the overall _content_ of the table, like 
> "This table
> charts the number of cups of coffee consumed by each senator 
> - -", but this
> probably means basically that "purpose" is meant to be read 
> as a content
> description, rather than telling the real purpose, i.e. _why_ a table
> presents some statistics about senators' coffee consumption. 
> I feel a bit
> like a harmonizing exegetic, but I think this interpretation 
> more or less
> resolves the doublesidedness:
> 
> A summary is supposed to describe the structure of a table, 
> in a manner that
> covers the meanings of columns and rows, thereby giving an idea of the
> overall content en passant.
> 
> Literally taken, this discussion means that summary="" would 
> say that the
> table has no structure and, moreover, that it has no purpose 
> (if we take the
> word "purpose" in the specification literally) or that it has 
> no content
> (since an empty overview of a content is adequate only if there is no
> content).
> 
> However, one might read "table" as relating not the the table 
> element, with
> all its content, but to the pure structure itself. Even then, 
> summary=""
> would be problematic.
> 
> It is tempting to say that the lack of a summary attribute 
> should indicate
> that table is for layout only. But since the great majority 
> of tables on Web
> page currently has no summary attribute, such a criterion 
> would lead to
> definitively wrong conclusions.
> 
> What I suggest is this (and I might be simplifying the situation):
> 1. For a table used for positioning elements on screen, e.g. 
> so that there
> is some material on the left and some other material on the 
> right, use a
> summary attribute that explains the contents of the cells. In 
> a way, treat
> it as a structural table. Example: summary="First cell: 
> navigation links.
> Second cell: content proper." If there are cells with no 
> content, used just
> to create borders between content cells for example, I think 
> you should
> state this explicitly, like "Fourth cell: no content."
> 2. For a single-cell table used for formatting purposes such 
> as setting a
> fixed width for text or to create a border around it, use a summary
> attribute that describes the content of the cell. Example: 
> summary="Copy
> text. (This is the only cell in the table.)"
> 
> One of the points here is to be prepared to software that 
> processes tables
> in an "unconventional" but logical way, giving the user 
> access to each cell
> separately, in some suitable manner.
> 
> -- 
> Jukka Korpela, senior adviser 
> TIEKE Finnish Information Society Development Centre
> http://www.tieke.fi/
> Diffuse Business Guide to Web Accessibility and Design for All:
> http://www.diffuse.org/accessibility.html
> 
The information in this email is confidential. The contents may not be disclosed or used by anyone other than the addressee.  If you are not the addressee, please tell us by using the reply facility in your email software as soon as possible. Sheffield City Council cannot accept any responsibility for the accuracy or completeness of this message as it has been transmitted over a public network.  If you suspect that the message may have been intercepted or amended please tell us as soon as possible.

Received on Friday, 8 November 2002 03:33:12 UTC