RE: linearized tables

Len,

Thanks for noticing the formality. Such used to be my work.

I agree with everything you said. The only sensible (logical) conclusion
is to make a special case of a "data table" (true table, tabular data) with
headers and only one data row. It should linearize well, and your
prescriptions are great. In fact, I will use them as suggestions for a very
important intranet web site in IBM that was using exactly this technique.

BUT.  Going to the detail that your assessment requires is too much for
the content guidelines. I think your analysis belongs in an advanced text
on usability for accessibility. It is impossible to present this kind of
detail in
the guideline.  Well obviously it is not impossible. What is impossible is
that anybody will read it. Web developers don't have the time to go into
this
detail.

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


"Leonard R. Kasday" <kasday@acm.org> on 03/15/2000 09:05:41 PM

To:   James Thatcher/Austin/IBM@IBMUS, gv@trace.wisc.edu
cc:   "'Greg Lowney'" <greglo@microsoft.com>, "'Wendy A Chisholm'"
      <wendy@w3.org>, w3c-wai-gl@w3.org
Subject:  RE: linearized tables




At 09:01 AM 3/14/00 -0600, thatch@us.ibm.com wrote:
>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,

I've been trying to figure out how to answer this formal
characterization.  The problem I have with it is the practical consequence.

Lets say I'm dealing with a designer constructing this form we've been
talking about, with name, address and phone across the top and three fields
across the bottom (I'll the the fields FIELD instead of writing out <INPUT
type= etc. etc. etc. etc.>

If the designer construct this with a 2 row table, a typical user agent
will read it

name, address, phone, FIELD, FIELD, FIELD Clearly suboptimal.

But if the designer makes a trivial change... implementing it as a one-row
table, with name <BR> field in the first cell, address <BR> field in the
second, and phone <BR> field in the third, then it gets read

name, FIELD, address, FIELD, phone FIELD.

In other wise, an easily understood reading order.

If I follow your argument that linearization is not relevant, it means I
don't tell the designer to use the second, more accessible design.  I just
can't accept that.

But I've got to admit that, yes, formally speaking this is a table in the
data sense (something that greg said also) so technically speaking  I'm
stuck with this consequence.  So how to get out of this.  I suggest a new
requirement:

Ban the use of "degenerate" data tables, i.e. tables that only have one
data row (in addition to the headers).  Note that this does not apply to
tables with a variable number of data rows... e.g. results of search
operations.

Degenerate data tables may be replaced with presentations that preserve the
visual appearance, e.g.

  - a one row layout table with <BR> separating the (former) heading and
data in each layout cell
  - CSS positioning of the elements (only recommended when CSS layout is
universally bug free)

They may also be replaced by other layouts, e.g.
name: FIELD  <BR>
address: FIELD  <BR>
phone : FIELD  <BR>s

or a description list,

The choice is up to the author.

That way we recognize the formal characterization of the 2-row design as a
two row table, but avoid the undsirable practical consequence.

Does that sound OK?  If not, is there some other way to avoid the
consequence?  Are we  stuck with the consequence, driven to it by this
logical analysis?

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)

Received on Friday, 17 March 2000 00:03:44 UTC