- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Tue, 10 Feb 2004 14:17:54 -0500
- To: "WAI WCAG List" <w3c-wai-gl@w3.org>
- Message-ID: <002801c3f00a$9648abb0$a201a8c0@deque.local>
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. Thanks, 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!) 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 14:08:15 UTC