Re: Table evaluation

Michael,

> I think what the flowchart leaves out is how to decide whether a table is
a
> data or layout table...
>
The only sure way is to ask the author. We should consider giving some
guidance to the author so they can make the decision. But what is the
difference? Does not a data table 'layout' the data?

> 1. A layout table can have either data tables or layout tables within it.
> 2. A data table also might have data tables or layout tables within it.
>
Yes, I think both cases can occur.

> 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.
>
Yes, it muddies the data/layout table distinction.

Chris


----- Original Message -----
From: Michael Cooper <mcooper@cast.org>
To: <w3c-wai-er-ig@w3.org>
Sent: Wednesday, December 15, 1999 4:03 PM
Subject: 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 Thursday, 16 December 1999 09:46:13 UTC