Re: w3c - Scope attribute in Table tag

At 07:26 AM 7/12/2001 , Brooke Dine wrote:
>Yes, I'm just full of questions this week.  Thanks to everyone for the info on requirements/procedures.
>  
>Next question:  I'm attempting to figure out the proper method of tagging for tables.  In the past I had used <th> and <td> with "header" and "id" as per W3C.  However, the 508 requirements from the Access Board say to just use the scope attribute.  What do you all think?  Which is better for data tables? and layout tables?  Which readers pick up the scope tag?  

Tables are always hard to figure out.  I can tell you what I think 
should be done, but of course, I am not the Access Board so I can't
give you an answer on "what 508 requires".  Here goes:

Layout tables and data tables use the same markup, but do different
things.  They need to be be treated differently as far as attributes. 
And "simple" data tables should be distinguished from "complex" data
tables.  Here is my summary list of suggestions for tables:

LAYOUT TABLES:

1.  Indicate layout tables with a human-readable @summary attribute
     reading something like "Page Layout."

2.  Only use <td> elements for layout.  Do not use <th>, or any other
     elements such as <thead>, <tbody>, <caption>, etc.

3.  Do not use @headers, @scope, or @axis on layout tables.

4.  Test your layout to make sure that it makes sense when read in
     linear order -- the order in which it appears in the source code,
     usually.  (Change all <td> and <table> tags to <div> to test.)

5.  Use CSS and/or HTML @align and @valign attributes to make your
     page layouts align properly.  This probably won't break anything.

6.  Don't use a @title element on your layout table, or on any
     cells of your layout table.  This will cause unwanted tooltips.

7.  OPTIONAL:  Consider creative use of @colspan and @rowspan, and/or
     nested tables, in order to make your layout work linearly as well
     as graphically.

DATA TABLES:

1.  Use the @summary attribute to list the data represented; don't
     just name it.  Don't say, "Listings of television shows on
     tonight," instead say "On channel 2, the news from 8 to 10. On
     channel 3, the movie 'Jaws' from 7:30 to 11:00. ..."

2.  Note!  It will get tedious to do the above, and probably won't
     all fit nicely in one attribute.  Therefore, if your summary is
     going to be more than about 200 characters (as it probably 
     will be), you should provide a link OUTSIDE of the table
     reading something like "Text summary of table" which goes to
     a page with a long summary.  Then make the @summary attribute
     read, "Listings of television shows on tonight: Summary link 
     follows table."

3.  Use <th> tags for a header -- and a header is anything where
     the content of the <th> applies to everything else in the same
     row or column.  For example:  I have a matrix that lists 
     availability of various products in various stores.  Across
     horizontally on the first row, I list my products, one per
     column.  Going down, I list my store locations, one per row,
     and the rest of the row is the intersection of the product and
     the store data.  The cells with the product identifiers, and
     the cells with the store identifiers, should both be <th>
     elements.

4.  Use CSS and/or HTML @align tags to style your <th> headers if 
     you don't like the default appearance.  This won't break anything.

5.  If you're creating a large table, consider using <thead>,
     <tfoot>, <tbody>, <colgroup>, and <col>.  The purpose of these
     elements and attributes is to allow you to group together
     rows or columns and give them a special designation.  This can
     be useful for styling, scrolling, or printing, but is usually
     going to be overkill on any table with less than 50 cells.

6.  Consider using abbreviations for your headers.  There are
     two issues here, and I'll try to untangle them for you.  If
     you want to display a short header which logically means
     something larger -- such as using "PID" instead of "Product
     Identification" -- then you will use the <abbr> tag within
     the <th> to offer up the longer expansion.  If you want
     to display a long header, such as "Store Located in Temecula,
     California", you should consider using an @abbr attribute
     on the <th> tag, with a value such as "Temecula."

7.  Use a <caption> attribute to label your table if the content
     requires it.  Don't use @title to label your data table.

IDENTIFYING SIMPLE DATA TABLES:

The "rules" are different -- or at least, lots of stuff is unnecessary --
if you are dealing with a "simple" table vs. a complex one.

1.  If you use @colspan or @rowspan, your table is not simple.

2.  If you have "nested headers", then your table is not simple. 
     Nested headers means that more than one row header or more than
     one column header applies to the same content.  Let's look
     at the product-store matrix -- if the first row, before the
     listing of stores, were a row with headers reading "Product
     Type", and under that, the specific product.  Two column
     headers ("Product Type" and the name of the product) would apply
     to each cell.

3.  If you've got headers which are not on the far edges of your
     table -- on the top, the bottom, the left, or the right -- then
     you don't have a simple table.  For example, if row one is a
     list of headers representing "data prior to 1994" and row
     fifteen is a list of headers representing "after 1994", and
     it splits your table in two, because you've got different
     headers going across.

4.  As the most simple check, each cell should be in a row with
     only one row header in it, and in a column with only one
     column header it, and both of those should be applicable headers 
     to the cell.  If this is not the case, then you don't have a
     simple table.  For example:  more than one row header, more
     than one column header, a column or row header which doesn't
     apply (see #3).

SIMPLE DATA TABLES:

1.  Don't use @scope, @headers, or @axis attributes on your simple
     table cells.

COMPLEX DATA TABLES:

1.  Decide how you are going to associate data cells with headers.
     There are three approaches:  @headers, @scope, and @axis.
     They are not incompatible with each other, so you can get
     pretty complex.

2.  @scope assumes that you can designate a header as applying to
     "everything in this row" or "everything in this column", or
     even "everything in this group of rows or columns," where
     the row, column, colgroup, or rowgroup is the one containing
     the header cell.  This is how simple tables work, but it may
     need to be spelled out for complex tables.  @scope is an
     attribute set on the header cell, not on the data cells.
     (You may need to use <tbody>, <colgroup>, and <col> to
     designate groups of rows or columns.)

3.  @headers takes the opposite approach -- it assumes that you
     may not be able to easily a header as applying to to whole 
     rows, columns, or groups thereof.  You designate the relationship
     on the data cells themselves, not on the header cells.  The
     header cells simply need an @id attribute to be set.  More
     than one header can be applied to each cell; you just give
     a list of header ids separated by spaces.

4.  @axis gets even stranger.  @axis lets you associate together
     cells, groups cells associated by @headers, and groups of cells 
     associated by @scope.  You set the @axis attribute on a cell, 
     and that cell is part of the axis defined by that value.  If
     the cell has a @scope attribute set, the cells within that
     scope are part of the axis.  If a cell with an @axis has an 
     @id, then any other cells which list the id in their @headers
     attributes are part of the @axis.  In theory, this lets a
     browser "query" a table and return information.  In practice,
     I don't know of any browsers which do that, and in general,
     if you are at this level of complexity then you perhaps should
     offer your content in alternate formats, or perhaps in multiple
     tables.


Hope this helps.

I've also put this summary up on http://access.idyllmtn.com/tables/

--Kynn

--
Kynn Bartlett <kynn@reef.com>
Technical Developer Liaison
Reef North America
Accessibility - W3C - Integrator Network
Tel +1 949-567-7006
________________________________________
BUSINESS IS DYNAMIC. TAKE CONTROL.
________________________________________
http://www.reef.com

Received on Thursday, 12 July 2001 13:07:20 UTC