RE: [#248] Table Proposals

I apologize if this message sounds like a 'newbie', but what exactly can
be communicated using table markup in layout tables that would benefit
the user and why can't that information be provided as text so as to
benefit all users,  not just those with screen readers?

In tests I've conducted with JAWS, the problem is often too much
information- cacophony, rather than too little.

Chris Brainerd
Instructional Designer
Real Choices ACCESS
Center on Disability Studies
University of Hawaii
Chris.brainerd@cds.hawaii.edu
808-956-9356

-----Original Message-----
From: Al Gilman [mailto:asgilman@iamdigex.net] 
Sent: Wednesday, June 11, 2003 3:30 AM
To: WAI GL (E-mail)
Subject: Re: [#248] Table Proposals



At 01:36 PM 2003-06-06, Michael Cooper wrote:

>Here is a new set of table proposals. There are a couple issues that we

>couldn't decide on (use of the summary attribute, and use of <thead>, 
><tfoot>, <tbody> etc. in layout tables), so those are raised in a 
>separate message. Hopefully these proposals can be considered clear and

>appropriate and accepted wholesale, but if particular ones give us 
>trouble, please send your thoughts. Michael

I think the GL/Techniques folks are working with a 'scope' concept that
is not obvious to me.  PF and HTML WG people are at this time more
focused on XHTML2, where we want to re-engineer the format some and are
not limited to the HTML4 model.  But it could be that all these
statements are predicated on the HTML4 model of what can be expressed in
markup.

Question: does the call today deal with

- how to use the existing markup capabilities in HTML4 and its
derivatives (which is intended to mean everything up through XHTML 1.1)

- a model of interaction with structured information that works in
conjunction with tabular layout

.. or both?

>1. Data tables and layout tables are two distinct uses of the <table> 
>element and have different requirements.

What is not clear in this statement is whether there is an 'other'
category as well.

If the assertion is that "data tables" and "layout tables" as described
below partition the uses of the TABLE markup in HTML cleanly, then I
would have doubts.  I would characterize these two as "regular data
tables" and "pure layout tables" and would suspect that on the Web as it
is we will find many instances of table markup that do not fit the
strict definitions laid out for these two categories.

>a. Data tables: contain a regular organization of cells, the meaning of

>which is contextualized by specific relationships among the cells. 
>Moving a cell would change the meaning conveyed by the table.

Suggested edits:

from "is contextualized by specific relationships"

to "is incomplete without understanding specific relationships"

from "moving a cell"

to "exchanging the contents of two cells"

[not clear how one can move just one cell and retain the regular outer 
structure]

>b. Layout tables: organize information visually but do not convey 
>meaning through the table's structure. Moving a cell may alter the 
>organization of the information but does not affect intrinsic meaning 
>implied by the relationship of the cells.

None of these distinctions is crisp.

"convey meaning through the table's structure" is not a yes/no thing.
There are many cases where structure that relies on the grid graphical
structure constructed by the TABLE rendering is significant, meaningful.

There are a variety of semantic patterns that occur in classical tables:

a: cells grouped aligned that go together and are easier to interpret as
a group than each in isolation.

b: separating common characteristics of multiple cells off into meta
cells that apply to or qualify a collection of other cells.

c: a recurrence pattern in which the same internal structure is repeated
multiple times.

Pattern c doesn't usually appear without either pattern a or b, but a
and b may appear independently and are not always found together or
absent.

>2. Requirements for data tables:

How can you determine the data-structure requirements for structured
data without first visiting the alternative interaction schemes that
work for different user groups?

What does AT do with tables today?  What does this tell us about our
data structure requirements?  There is a great leap here without any
rationale.

>a. Data tables MUST contain <th> header elements to label categories of

>data. Headers may be used for columns, rows, or both.

The requirement is that the value in the cell should be well explained.
If we try to say that such tables have to have headers, we will generate
resistance from authors, because this will require layout space where
they don't want to spend it at times.

If the value as expressed in the contents of the cell is
self-explanatory, then no metadata are required.  Looking forward, PF
has been pushing that types and schemas for data values be used as the
primary means of clarifying data values.  This will give the information
to populate TH cells when the recurring pattern of sub-patterns is not
enough to cue this information in the composed visual display.  Tables
are used [as opposed to lists and paragraphs] where there is a lot of
information to present and space is at a premium.

>b. Data tables that have more than one row of column headers and/or 
>more than one column of row headers MUST use additional markup to 
>clarify the relationship of data cells to their headers.

The current level of orthodoxy in using TH is low.  This element is used
as much for styling as for schematizing.  What makes us think we can
gain adoption of this encoding of this semantic?  As a matter of format
design, it is better to capture the TD -to- TH relationship in
relationship markup, and not infer it from element-type markup (TD vs.
TH distinction).

The marking of "is metadata for" relationships should come at a highter
priority than making a distinct element type for metadata.  TH is a
kluge.

>This should include "id" and
>"headers" attributes OR "scope" attributes. "scope" attributes MAY 
>require proper use of <col>, <colgroup>, and <tbody> elements.

Does anybody have current "until user agents" information on the 'scope'
technique?  At the time of the FedStats workshop on accessible markup
for complex tables, HEADERS had better implementation than SCOPE.

  http://workshops.fedstats.gov/FS508Workshop.htm

>c. Data tables whose structure is not completely apparent by use of the

>above header markup SHOULD use the "axis" attribute to provide 
>additional clarification.

Does any AT implement "axis"?  What do they do?  What is it supposed to
contain if it is used?

...etc.

>d. Data tables SHOULD use <thead>, <tfoot>, <tbody>, <col>, and 
><colgroup> elements to organize rows and columns of information if the 
>logical structure is more complex than a simple two-dimensional grid. 
>e. Data tables SHOULD use the <caption> element to label the table.
>
>3. Requirements for layout tables:
>
>a. Layout tables MUST NOT use <th> header elements or any of the header

>structure attributes "headers", "scope", or "axis". Document structure 
>should be conveyed by other structural elements such as headings (<h1> 
>- <h6>).

This is counter to the thinking at the time of the HTML4 accessibility
review.  [will explain on the call, running out of time.]

>b. Layout tables MUST NOT use the <caption> element.

This is nonsensical.  The CAPTION applies to the whole object whether it
is a TABLE or a figure.  There is no reason to disallow it for graphical
arrangements outside the narrow class of the regular data table.

>c. The source code order, or default linearization, of layout tables 
>MUST result in the contents being able to convey the author's intended 
>purpose.

Is this still relevant?  How much are we sacrificing here to lagging 
technology?

>4. Remove the requirement that a text equivalent be provided for layout

>tables that render columns of text.

How is the AT supposed to know that a later column (but earlier row)
cell continues the text that is incomplete at the bottom of an earlier
column?

Or are you assuming that each column of wrapping text is a single cell
as far as the table is concerned, so that reading-order flow and the
hypertext flow are in the same order?

Al

>Michael Cooper
>Accessibility Project Manager
>Watchfire
>1 Hines Rd
>Kanata, ON  K2K 3C7
>Canada
>+1 613 599 3888 x4019
>http://bobby.watchfire.com/

Received on Wednesday, 18 June 2003 19:02:02 UTC