RE: [#248] Table Proposals

I agree with Chaas (and Chris): if the onscreen <caption> can provide
enough information to help everyone, a null summary is a good idea.

John

John Slatin, Ph.D.
Director, Institute for Technology & Learning
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.ital.utexas.edu
 


-----Original Message-----
From: Charles McCathieNevile [mailto:charles@w3.org] 
Sent: Thursday, June 19, 2003 1:25 am
To: Chris Brainerd
Cc: Al Gilman; WAI GL (E-mail)
Subject: 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 09:08:26 UTC