RE: layout tables

One problem I have observed with this is that if *every* table has a
summary, including the tables used strictly for layout purposes, users of
screen reading technology get inundated with more information than is
practically neccessary under *normal* solutions.

For example, if a page maintains a persistent table at the top of every page
for navigation "buttons", is it really neccessary to tell every user (every
time) that "This is a table for laying out the navigation buttons"? ("This
is a pen which is used for writing"). The net effect is that we are then
being "overly verbose" to this type of technology.

If, to avoid this, the user of the screen reader "disables" or reduces the
verbosity of their application, what then happens when they reach a table
which *really* requires an appropriate summary?  They don't get it...

Chaas has correctly suggested that the best way to avoid this problem is to
avoid using tables for layout purposes, but as we all know, in the real
world that may not be an option available to us.  I would suggest then that
Kirsten's approach of providing {summary=""} to the layuout tables satisfies
some of the testing tools which cannot mechanically ascertain the difference
between the layout table and the data table.

Perhaps the better solution would be to re-write the checkpoint
acknolwedging the difference between layout and data tables?

JF


> -----Original Message-----
> From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
> Behalf Of Scarlett Julian (ED)
> Sent: Friday, November 08, 2002 3:35 AM
> To: wai
> Subject: 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
> >

Received on Friday, 8 November 2002 07:10:28 UTC