W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2000

RE: linearized tables

From: <thatch@us.ibm.com>
Date: Tue, 14 Mar 2000 09:01:26 -0600
To: gv@trace.wisc.edu
cc: "'Greg Lowney'" <greglo@microsoft.com>, "'Wendy A Chisholm'" <wendy@w3.org>, w3c-wai-gl@w3.org, kasday@acm.org
Message-ID: <852568A2.00534035.00@d54mta08.raleigh.ibm.com>


How do you distinguish tables used for layout and those for tabular data? I
think the distinction is when the row-column position has meaning.

TV listings, for example, are "tabular data." The layout of tabular data
lets the sighted user observe the row-column semantics. Layout and tabular
data get kind of mashed together.  I think (hope) no one is arguing that
tabular data needs to linearize well.  Instead, use appropriate table
markup, TH elements and headers attributes, summary attribute and caption
element.

The example of a form whose input elements are placed in a table with
labels in the cells above is tabular data because row-column position
carries meaning. Clearly tabular data is not restricted to numbers. TV
Listings have very few numbers. The Form example is no less a table than
the TV listings. The Form example is properly marked up if appropriate
table markup is used. Of course the form can also be marked up with the
LABEL element.

My bottom line is that when row-column position carries meaning, then
linearization is not relevant.

Jim Thatcher
IBM Accessibility Center
(512)838-0432
After 3/31/2000 jim@jimthatcher.com (512)306-0931


"Gregg Vanderheiden" <gv@trace.wisc.edu> on 03/13/2000 08:46:25 PM

Please respond to gv@trace.wisc.edu

To:   "'Greg Lowney'" <greglo@microsoft.com>, "'Wendy A Chisholm'"
      <wendy@w3.org>, w3c-wai-gl@w3.org
cc:   kasday@acm.org
Subject:  RE: linearized tables




Hi Greg,

I think the problem is that most programs linearize by listing the items in
the order they are appear in the HTML.  So labels above items would not
linearize in any very usable fashion.

This is not a problem with tables that present tabular information.  In
that
case - the column headers across the top (If appropriately marked) would be
the proper way to lay out a table.  (especially since there are usually
labels down the side too.)  Not that the linearization rule does not apply
to tables used for tabular information.

It WOULD be a good idea for programs that linearize tables to give the user
the option to flip it top-for-side to see if it were easier to understand
or
use in that manner.  I don't know which ones do that though.   Anyone know
of table linearizers with a flip layout function?

Gregg


-- ------------------------------
Gregg C Vanderheiden Ph.D.
Professor - Human Factors
Dept of Ind. Engr. - U of Wis.
Director - Trace R & D Center
Gv@trace.wisc.edu, http://trace.wisc.edu/
FAX 608/262-8848
For a list of our listserves send "lists" to listproc@trace.wisc.edu

 -----Original Message-----
From:     w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]  On
Behalf Of Greg Lowney
Sent:     Monday, March 13, 2000 11:46 AM
To:  Wendy A Chisholm; w3c-wai-gl@w3.org
Cc:  kasday@acm.org
Subject:  RE: linearized tables

Hi Len, I don't necessarily disagree that it should be priority 1 to make
tables understandable when linearized, but I don't like the example: "a
form
laid out in a table with field labels on the top row and corresponding
fields on the bottom row."

I believe that complies with the guideline that requires the table to make
sense when linearized. It is normal table behavior for the first row to
label the entire columns, so from the standpoint of the guideline regarding
linearization it should be OK to create a table whose first row contained
labels for the form controls in lower rows. The responsibility then is on
the agent doing the linearization to clearly express the labeling
relationship between the column header and the cell contents. That's
equally
true whether the cell contains a control or any other content. Therefore I
don't see the example as violating this guideline.

However, the example would violate a second guideline, which is to ensure
that implicitly-associated labels are properly positioned. That is Pri 2
because it's assumed that the author will comply with the third guideline,
that of providing explicitly-associated labels.

     Greg

-----Original Message-----
From: Wendy A Chisholm [mailto:wendy@w3.org]
Sent: Friday, March 10, 2000 12:08 PM
To: w3c-wai-gl@w3.org
Cc: kasday@acm.org
Subject: Fwd: linearized tables



>Resent-Date: Fri, 10 Mar 2000 11:39:32 -0500 (EST)
>X-Sender: kasday@pop3.concentric.net
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
>Date: Fri, 10 Mar 2000 11:41:49 -0500
>To: "wai-wcag-editor@w3.org" <wai-wcag-editor@w3.org>
>From: "Leonard R. Kasday" <kasday@acm.org>
>Cc: w3c-wai-er-ig@w3.org
>Subject: linearized tables
>Resent-From: w3c-wai-er-ig@w3.org
>X-Mailing-List: <w3c-wai-er-ig@w3.org> archive/latest/1144
>X-Loop: w3c-wai-er-ig@w3.org
>Sender: w3c-wai-er-ig-request@w3.org
>Resent-Sender: w3c-wai-er-ig-request@w3.org
>
>WCAG says
>
>5.3 Do not use tables for layout unless the table makes sense when
>linearized. Otherwise, if the table does not make sense, provide an
>alternative equivalent (which may be a linearized version). [Priority 2]
>
>This means that someone could use tables for layout in way that the page
>makes no sense and is not usable by any of todays user agents... but still
>get an A conformance rating, because this is only priority 2.
>
>For example, if there's a form laid out in a table with field labels on
>the top row and corresponding fields on the bottom row.
>
>I think the checkpoint needs to be Priority 1.
>
>Len
>
>-------
>Leonard R. Kasday, Ph.D.
>Institute on Disabilities/UAP, and
>Department of Electrical Engineering
>Temple University
>423 Ritter Annex, Philadelphia, PA 19122
>
>kasday@acm.org
>http://astro.temple.edu/~kasday
>
>(215) 204-2247 (voice)
>(800) 750-7428 (TTY)

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--
Received on Tuesday, 14 March 2000 10:09:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:01 GMT