Re: Layout versus data tables proposal for null summary attribute

I'm not sure that you mean that if an empty summary is applied that the
table will be skipped by screen readers as you indicate later in the message
that the only benefit to summary is for screen readers and that the only
advantage and probably rightly so that comes from adding summary everywhere
is for screen readers.  I Imagine that there could be if there are not
already advantages to adding summary in appropriate tables.  I do agree
though that we should not have summary everywhere.  Authoring tools should
do a better job of helping to determine this huristically and testing tools
just need to get better at looking at code.  I have no problem with a tool
telling me that this is a table and if it is a data table it needs a summary
and if a lay out table, it does not so that the tester can intervene here.
I do however like the consistancy of using summary everywhere and applying
the empty principle since some current testing tools seem to require
summaries no matter what the table is and current authoring tools seem to
produce tables with reckless abandonment.

Johnnie Apple Seed

----- Original Message ----- 
From: "Bart Simons" <bart.simons@ascii.be>
To: "W3c-Wai-Ig@W3. Org" <w3c-wai-ig@w3.org>
Sent: Monday, August 30, 2004 6:09 AM
Subject: RE: Layout versus data tables proposal for null summary attribute



> From: "Phill Jenkins" <pjenkins@us.ibm.com>
> the proposal is to recommend a best
> practice for distinguishing between data tables and layout tables by
> including the summary attribute, but leaving the contents empty (null).
>
Does this mean that a layout table can't contain a descriptive summary?

> Simple Example:
>
> <table title="layout table for navigation" summary="">
>
The vast majority of tables on the web  still are layout tables. It will
take years to add this attribute to existing web pages. As it does not have
a clear function, it will be hard to convince content providers to do so.
I foresee that designers are going to add the summary="" attribute to all
new tables they create without asking themselves whether it is a data table
or not. If they forget to add a text between the quotes of the summary
attribute these tables will be ignored by screenreaders as well which may be
more confusing.

> Layout tables are those tables in HTML that do NOT have row and/or column
> headings (TH's), do NOT have Captions, and do NOT have other mark-up
> associated with tabular data for which the table markup was originally
> specified.
>
I agree that this definition is circular in a sense. It does not describe
when captions should be used.

> Data tables are those tables in HTML that do or should have row and/or
> column headings (TH's), do or should have captions, and do or should have
> other markup, such as summary, scope, and other attributes and elements
> associated with tabular data.
>
I prefer the definition stating that in a data table the content of two
cells can't be rearranged as their meaning changes. Or, the contents of one
cell depends at least on another cell next or on top of it.

> Other proposals included using the title attribute to include the keyword
> "layout".

I am not in favour of this proposal for the reasons you mentioned.

> The proposal to use the null summary="" attribute has the following
> benefits:
> 2. The summary attribute can be checked for null by authoring tools as a
> convention to indicate the table is for layout.  If we eliminated the
> summary attribute completely from the markup, then there is less of a
> guarantee that the author made a conscience decision to identify the
> articular table as a layout table.

If every web designer is supposed to determine which table is for layout and
which is for data, we need a much clearer definition. The fact that this
discussion is held for several years proofs that it is impossile to rely on
designers to make this decision. As long as we don't agree on the definition
of a data table, the man in the street won't either.

> 4. The user agent could be configured to skip or ignore layout tables
> identified with the null summary="" attribute when navigating.

This seems to be the only advantage as no other users than screenreader
users benefit from the summary attribute.

JAWS already does a good job in ignoring them. Talbes with one column and/or
one row are threated as layout tables. This works pretty good without false
negatives.

> 5. Authoring tools could be more intelligently configured to test for
> reading order in layout tables and correct tabular data markup in data
> tables.
>
Why do you need the empty summary attribute for this?
Tables are already are a complex issue in web accessibility. Why are we
making it more complex again by adding the need for a summary attribute
everywhere?

Regards
Bart

Received on Monday, 30 August 2004 11:08:45 UTC