W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2004

Re: [html-techs] Table Type

From: Sailesh Panchang <sailesh.panchang@deque.com>
Date: Tue, 10 Feb 2004 14:17:54 -0500
Message-ID: <002801c3f00a$9648abb0$a201a8c0@deque.local>
To: "WAI WCAG List" <w3c-wai-gl@w3.org>
  Hello All,
  My thoughts / observations:
  1. A data table must be at least 2 X 2 in size and  in order to understand the content of any  td cell it must be necessary to relate it to its column header and row header (identifier). And conversely, all td cell contents in a row or column should bear a relation  to the row or column header respectively. 
   If the  td contents  makes sense on its own, then the table may be regarded as a layout table. 
  2. Should be possible to listHTML elements that   are out of place in a real data-table. For instance it does not make sense  to embed a data table within a td of a data table. (One does see them but it is  not good design in my opinion because a zoomed-in view of that cell is outside the structure of the main table). 
  3. JAWS  is the only screen reader that allows table navigation  in forms mode and that is real good. WinEyes4.5  and HPR 3.02 do not.
  John wrote:
  >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.
  This behavior  is dependent on  the technique used to code a form embedded in a table. First one needs to identify whether  the table is a data table or is used only for layout purpose. If it is the latter, then the label method must be used to associate them to controls. This  is the route one must take when  there is a one to 
  one relation with a label and control.  
   In this situation, it does not make sense to navigate the form in table navigation mode and quite logically,  JAWS table navigation fails in forms mode.
  A two column table with left column containing  labels for form controls in the right column  is essentially a layout table as  the contents of the first row are not really column headers for the table. The label method is proper in this case.
  But when more than one control can be associated with a label, then one must adopt the data table approach for coding a form. The label element must not be used but the title attribute should be used on every form control to identify its row and column. This form is navigable in table mode whether in or out of forms mode with JAWS. Of course, th must be used for column and row headers (first row and left most column).
  Example 1: Travel Expense reporting form:
  Columns are: Serial#, Date, Place, Meals($), Hotel($),Transport($). The serial# is a row identifier.
  There can be more than one row of data and  there are  a series of controls associated with everyrow OR  column header. 
  Example 2: Inbox (or any e-mail) folder
  Column header: From, Date, Size,Checkbox.
  The "From" field in rows of data is a hyperlink to the message. Size and date are display fields and  checkbox can be activated to select/deselect the message.
  Selected messages can tbe  deleted or moved  to another folder by  activating a button at the start of the table. This table can be navigated in table mode (out of forms mode) and checkbox can be  checked/unchecked with spacebar.
  Sailesh Panchang
  Senior Accessibility Engineer 
  Deque Systems,11180  Sunrise Valley Drive, 
  4th Floor, Reston VA 20191
  Tel: 703-225-0380 Extension 105 
  E-mail: sailesh.panchang@deque.com
  Fax: 703-225-0387
  * Look up <http://www.deque.com> *

  ----- Original Message ----- 
  From: John M Slatin 
  To: Chris Ridpath ; Yvette P. Hoitink ; WAI WCAG List 
  Sent: Tuesday, February 10, 2004 12:04 PM
  Subject: RE: [html-techs] Table Type

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

  -- 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!)


  "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
  > in two rows with headers to the left in separate cells...
  Here's the table I think you're describing:

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

  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

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

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

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


  ----- Original Message ----- 
  From: "Yvette P. Hoitink" <y.p.hoitink@heritas.nl>
  To: "'Chris Ridpath'" <chris.ridpath@utoronto.ca>; "'WAI WCAG List'"
  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
  > 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
  > 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
  > associated with different headings. Does that make it a data table? I
  > think so. The table has no benefit here besides the visual aspect, the
  > 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
  > if it fits your definition.
  > A more interesting example is if you use a table to do the layout of a
  > (labels in column 1, inputs in column 2) Moving a cell changes its
  > 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
  > 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
  > 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,
  > 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
  > 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.
  > the labels correctly with their inputs in HTML is not possible in this
  > 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 14:08:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:47 UTC