RE: [html-techs] Table Type

A small addendum to the example of a table used to lay out a form:

Recent versions of the JAWS screen reader don't appear to recognize the
table markup once the user has entered forms mode: JAWS reports the
label elements but not the row or column headers as such.

-- Having said that, I hear Joe Clark reminding us not to confuse what a
particular screen reader implementation does with what *should* happen,
and I would agree-- it would be good to be able to find out both the
specific label for a specific control and the larger category to which
it belongs.  Fieldset and legend can do this in some cases, but I think
not all-- especially not in layout tables, where a fieldset has to be
entirely contained within a single table cell in order to work (I think:
again this may be JAWS specific, and I'd be glad if it turns out not to
be generally true!)

John


"Good design is accessible design." 
Please note our new name and URL!
John Slatin, Ph.D.
Director, Accessibility Institute
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.utexas.edu/research/accessibility/


 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Chris Ridpath
Sent: Tuesday, February 10, 2004 10:49 am
To: Yvette P. Hoitink; 'WAI WCAG List'
Subject: Re: [html-techs] Table Type



I agree that there will be grey areas but let's see if we can clarify
most of them.

> Hypothetical example: If I have have a 2x2 (layout) table to divide my
text
> in two rows with headers to the left in separate cells...
>
Here's the table I think you're describing:

<table>
<tr><th>Heading 1</th><td>Some text.</td></tr>
<tr><th>Heading 2</th><td>More text.</td></tr>
</table>

I believe that this could be a layout table with improper use of the TH
element. Remove the first column of TH elements. Place the heading text
within the TD elements and mark it as such (i.e. H2).

> I see no value in using the semantic
> markup for data tables here so to me this is definitely a layout 
> table...
>
TH elements are semantic markup and should not be used in your example
table.

> A more interesting example is if you use a table to do the layout of a
form
> (labels in column 1, inputs in column 2) ...
>
Here's what I think you're describing:

<form>
<table>
<tr><td><label for="id1">label 1</label></td><td><input type="text"
id="id1"/></td></tr> <tr><td><label for="id2">label
2</label></td><td><input type="text" id="id2"/></td></tr> </table>
</form>

Yes, grey area. Technique 14.4 already says to label form controls so
the use of TH may be optional here.

Chris


----- Original Message ----- 
From: "Yvette P. Hoitink" <y.p.hoitink@heritas.nl>
To: "'Chris Ridpath'" <chris.ridpath@utoronto.ca>; "'WAI WCAG List'"
<w3c-wai-gl@w3.org>
Sent: Tuesday, February 10, 2004 10:46 AM
Subject: RE: [html-techs] Table Type


>
> Chris:
>
> >
> > How to determine if a table is data or layout:
> >
> > Discussed at length on this mailing list[2][3][4] etc.
> > In summary - If cells can be moved without affecting their intrinsic

> > meaning then it's a layout table. Corollary - If moving a cell 
> > affects its intrinsic meaning then it's a data table.
> >
>
> Sorry to open this cesspit again, but I really think tables used for
LAYOUT
> are layout tables, even if moving a cell can affect its intrinsic 
> meaning. There will always be grey areas: tables used for layout that 
> might benefit from semantic markup. But does that make them data 
> tables?
>
> Hypothetical example: If I have have a 2x2 (layout) table to divide my
text
> in two rows with headers to the left in separate cells, exchanging 
> those cells can affect their intrinsic meaning as well because those 
> texts are
now
> associated with different headings. Does that make it a data table? I
don't
> think so. The table has no benefit here besides the visual aspect, the
same
> effect could be achieved through CSS. I see no value in using the 
> semantic markup for data tables here so to me this is definitely a 
> layout table
even
> if it fits your definition.
>
> A more interesting example is if you use a table to do the layout of a
form
> (labels in column 1, inputs in column 2) Moving a cell changes its
intrinsic
> meaning so it fits your definition of a data table, a viewpoint shared

> by Jim Thatcher [1].
>
> I still think of this as a layout table though, but I can see the 
> value in associating headers with the cells. From a practical point of

> view it may
be
> very helpful to use the semantic markup for data tables in tables used

> to layout forms, but on a principal level I do not regard tables used 
> for
form
> layout as data tables.
>
> An example of a search form which would benefit from more semantic 
> markup for the table can be found in a Dutch genealogical website: 
> http://www.genlias.nl. I can't give you a direct link to the search 
> page,
so
> please select English (top right corner) -> Searching the Genlias 
> database (text above the looking glass).
>
> This search form consists of three columns: column one has the labels,

> column two has the inputs for the first person you're looking for and
column
> three has the inputs for the second person you're looking for. The 
> meaning of an input is derived from two axis: the label and the 
> person.
Associating
> the labels correctly with their inputs in HTML is not possible in this
case,
> since HTML only allows one input per label. The authors have used <th>

> to indicate the column headers, but no other semantic markup.
>
> Yvette Hoitink
> CEO Heritas, Enschede, The Netherlands
> E-mail: y.p.hoitink@heritas.nl
>
> [1] Jim Thatcher argues tables to layout forms are data tables: 
> http://lists.w3.org/Archives/Public/w3c-wai-gl/2000JanMar/0406.html
>

Received on Tuesday, 10 February 2004 12:38:13 UTC