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, 11 June 2003 09:29:52 UTC