RE: [#248] Table Proposals

For example, I often provide a summary of a table's content (a real table) in
the caption element - visible by default to all users, and therefore in my
opinion much more helpful than an invisible attribute.

chaals

On Wed, 18 Jun 2003, Chris Brainerd wrote:

>
>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/
>
>

-- 
Charles McCathieNevile  http://www.w3.org/People/Charles  tel: +61 409 134 136
SWAD-E http://www.w3.org/2001/sw/Europe         fax(france): +33 4 92 38 78 22
 Post:   21 Mitchell street, FOOTSCRAY Vic 3011, Australia    or
 W3C, 2004 Route des Lucioles, 06902 Sophia Antipolis Cedex, France

Received on Thursday, 19 June 2003 02:24:39 UTC