RE: Table evaluation

Hi Chris -

I think what the flowchart leaves out is how to decide whether a table is a
data or layout table, and if it is a data table, whether it has nested
headers. The chart simply assumes you know that, and then identifies which
techniques to apply. I did it this way to help extract that "black box"
since the techniques were getting muddied with multiple, slightly different,
propositions. An implementation might choose to follow the flowchart,
preserving encapsulation, or might copy the (yet to be agreed on) algorithm
to make those decisions into the procedure for each technique. How we should
reflect this in the ERT document, I don't know.

And I really didn't address nested tables - partly because I forgot, and
partly because I don't see how that fits in. Here's my two cents on that
discussion, and when something crystallizes in the group I'll try to update
my visual arrangement.

1. A layout table can have either data tables or layout tables within it.
The table requirements would pretty much be applied to those child tables as
if there were not located inside a parent table. Since layout tables don't
have headers, we don't need to worry about that aspect.

2. A data table also might have data tables or layout tables within it.

2.1. A layout table inside a data table might be taken as a "data object"
with as much meaning as any other type of data cell contents. Probably the
header(s) for the appropriate cell of the outer table would apply to all
cells of the inner table collectively, sort of as if it had been linearized
into a single paragraph.

2.2. A data table within a data table should inherit, for each of its cells,
the headers that apply to the cell in the outer table of which it is a
member. It would be as if the inner table were just extra cells of the outer
one and not a separate table. From that perspective, the following two
examples would be equivalent, both in terms of how they render and in terms
of the meaning that should be applied to each cell for access and WAI
evaluation purposes:

Example 1 (data table, 2 rows by 1 column, with a nested data table of two
rows by two columns)
<TABLE CELLSPACING="0" CELLPADDING="0">
	<TR>
		<TH>Outer, R1C1</TH>
	</TR>
	<TR>
		<TD>
			<TABLE CELLSPACING="0" CELLPADDING="0">
				<TR>
					<TH>Inner, R1C1</TH>
					<TH>Inner, R1C2</TH>
				</TR>
				<TR>
					<TD>Inner, R2C1</TD>
					<TD>Inner, R2C2</TD>
				</TR>
			</TABLE>
		</TD>
	</TR>
</TABLE>

Example 2 (single data table, 3 rows by 2 columns)
<TABLE CELLSPACING="0" CELLPADDING="0">
	<COLGROUP COLS="2">
	<TR>
		<TH COLSPAN="2" SCOPE="COLGROUP">Outer, R1C1</TH>
	</TR>
	<TR>
		<TH>Inner, R1C1</TH>
		<TH>Inner, R1C2</TH>
	</TR>
	<TR>
		<TD>Inner, R2C1</TD>
		<TD>Inner, R2C2</TD>
	</TR>
</TABLE>

In both cases, the cells whose contents are "Inner, R2C1" and "Inner, R2C2"
have headers of "Inner, R1C1" and "Inner, R1C2" (respectively) and "Outer,
R1C1". In the second example that is explicit via table markup, and in the
first it is implicit via the nesting.

This would apply to any number of levels of nesting. However, if it got more
than a couple levels deep we might start to question whether the outer table
actually is a data table.

Again, hope this isn't just more confusing.

Michael

-----Original Message-----
From: w3c-wai-er-ig-request@w3.org [mailto:w3c-wai-er-ig-request@w3.org]On
Behalf Of Chris Ridpath
Sent: Wednesday, December 15, 1999 10:16 AM
To: Michael Cooper; w3c-wai-er-ig@w3.org
Subject: Re: Table evaluation


Michael,

Nice and clear. The flowchart is great. This seems to cover all the
techniques.

But will this cover tables embedded within tables? Eg. Can we assume that a
table within a data table is a data table (can't be used for layout)? Or do
we have to ask data/layout for all tables?

Chris

----- Original Message -----
From: Michael Cooper
To: w3c-wai-er-ig@w3.org
Sent: Tuesday, December 14, 1999 4:53 PM
Subject: Table evaluation


Hi, at our last teleconference we went in circles a bit about a desire to
encapsulate techniques for each Checkpoint separately, and the observation
that some things the E/R tool may discover may be relevant to how it should
process multiple Checkpoints under Guideline 5. I thought I'd try to
transform the ER Techniques for Guideline 5 into some other formats to see
if it helps us to see things better.

Attached is a .gif file "table_checks.gif" which contains a flowchart of how
I understand the current Techniques would work, and an HTML file
"table_checks.html" with a table that pretty much says the same thing. There
is also a text narrative at the bottom of this message in case the other two
formats are unusable.

The main thing I noticed when I did this is that we need to know whether a
table is a layout or data table in order to perform all Techniques except
5.5.A (provide summaries). Furthermore, if it is a data table we need to
know whether there are multiple levels of logical headers or not. Those
decisions seem like they could be made outside of specific Techniques - at
the cost of sacrificing encapsulation but with the benefit of making the
fewest number of total decisions.

Anyway, I hope this helps the discussion. Michael

Text description (hopefully not just more confusing)
For any TABLE:
1. Technique 5.5.A: check for a SUMMARY attribute;
2. Determine if this is a layout table or a data table;
2.1 If a layout table:
2.1.1 Technique 5.4.A: check for structural markup;
2.1.2 Technique 5.3.A: make sure it makes sense when linearized;
2.2 If a data table:
2.2.1 If there are multiple levels of logical headers;
2.2.1.1 Technique 5.2.A: check for multiple-level header markup;
2.2.2 Otherwise:
2.2.2.1 Technique 5.1.A: check for simple header markup;
2.2.3 Technique 5.6.A: check for header abbreviations
Done

Michael Cooper
Bobby Project Manager
Technical Designer
CAST, Inc.
39 Cross St.
Peabody, MA  01960
Tel 978-531-8555 x265
TTY 978-538-3110
Fax 978-531-0192
Email mcooper@cast.org
http://www.cast.org/
http://www.cast.org/bobby/

Received on Wednesday, 15 December 1999 16:10:42 UTC