Re: User agent support of SUMMARY attribute in tables

let's take a different tack here.  I don't have a dictionary handy, but I
know that the active form of summary is to summarize and what is there to
summarize about a lay out table?

It is not purely a question of screen readers, but one of taking an approach
to the language that provides us with guidance through it toward rendering
what is intended to be rendered.  Summary might need to be present for data
tables, even for those who can "look" at the table but not get a sense of
its wholeness unless guided by a summary. These fall into three clases.
Oneis low vision or braille readers who will find it valuable, two is
cognative in that they may only need the information found in the summary in
order to utillize the information and the third is a cognative type which
requires informational cues for spatial reasons.  I find good summaries of
data tagles extremeley helpful for several reasons which I will not go into
here.

----- Original Message -----
From: "Jukka K. Korpela" <jkorpela@cs.tut.fi>
To: "W3c-Wai-Ig" <w3c-wai-ig@w3.org>
Sent: Wednesday, January 22, 2003 4:40 PM
Subject: RE: User agent support of SUMMARY attribute in tables



On Wed, 22 Jan 2003, Nick Kew wrote:

> > How does AccessValet know the next time it is checking the site that the
> > table is "Not applicable"?
>
> Why is it re-checking the site?

Maybe the author changed something? Just a thought. :-)

> If a page hasn't changed since the last report, then we assume that
> any existing record is still valid

What existing record?

> It's a reporting tool, not a repair tool.

Understood, but the point is that if I run checks I don't want to answer a
zillion questions every time. This is a problem with A-Prompt, too, the
best automated accessibility checker at present, IMHO. I think the
experience with programming language linters should teach us that there
must be some way for an author to tell the checker "I know what I'm doing
here". Actually, it would usually be possible to decide, with a high
though not 100% reliability, whether a table is for layout or a data
table. If it has any of <thead>, <th> (especially with scope attribute),
<caption>, it's probably a data table. If it has lots of rowspan and
colspan and width attributes, probably it's a layout table.

Regarding summary, it seems that no consensus can be found. I understand
the points made about useless uttering of summary attribute contents (for
tables that are between layout and data tables) as well as about the
problem that summary="" might get pronounced. I would mostly classify
these problems as user agent deficiencies. After all, we don't frown on
alt="" just because some browsers might say something stupid about them.

But as a recommendation to authors, I think we can all agree that data
tables should have summaries, unless, perhaps, the text before the table
and the caption element have already explained the purpose and structure.
For layout tables, we might take the pragmatic approach that omitting
summary attributes is the simplest way and won't cause protests except
from checkers. And maybe it would be best if the next version or edition
of WAI guidelines specified this:
- use a summary attribute to give any information needed for understanding
  the structure of a table, to the extent that it is not explained
  otherwise in the document
- do not use summary attributes for layout tables.
(The first item might be accompanied with a statement saying that
the structure should be sufficiently obvious without the summary
attribute, too, but that attribute is mainly for explaining such
features that are obvious from looking at the table only, from
seeing it as a whole.)

If the guidelines clearly said that layout tables should not have summary
attributes, or at least said that they are not needed, checkers would have
less excuse for complaining about every table that lacks summary.

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Received on Wednesday, 22 January 2003 16:59:26 UTC