W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2001

RE : w3c - Scope attribute in Table tag

From: Jean-Marie D'Amour <jmdamour@videotron.ca>
Date: Thu, 12 Jul 2001 16:01:48 -0400
To: "'Paul Bohman'" <paulb@cpd2.usu.edu>, "'Brooke Dine'" <dine@ncbi.nlm.nih.gov>, "'Kynn Bartlett'" <kynn-edapta@idyllmtn.com>
Cc: "'w3cwai'" <w3c-wai-ig@w3.org>
Message-ID: <001001c10b0d$7bf32fe0$3543c818@ca.mshome.net>
Hello all,

Kynn's summary is very interesting and the precision add by Paul also.

For the scope attribute, it works fine in HPR but JAWS have a bug and
repeat twice each cell of the first row and the first column when you
read with the table navigation keystrokes.

Regards,

Jean-Marie D'Amour, M.Ed.
CAMO pour personnes handicapées
www.camo.qc.ca
Montréal, Québec, Canada

> -----Message d'origine-----
> De : w3c-wai-ig-request@w3.org 
> [mailto:w3c-wai-ig-request@w3.org] De la part de Paul Bohman
> Envoyé : 12 juillet, 2001 13:25
> À : Brooke Dine; Kynn Bartlett
> Cc : w3cwai
> Objet : Re: w3c - Scope attribute in Table tag
> 
> 
> Great summary, Kynn! One thing to be very wary of is the 
> rowspan attribute, as Kynn mentioned. If you have a row 
> header cell which spans more than one row, it will mess up 
> JAWS. Even if your markup is perfect, and you follow all of 
> the accessibility recommendations, JAWS has a bug that causes the
> *wrong* column header to be read with the data cell contents.
> 
> For an example of a table that would be read incorrectly by 
> JAWS, see http://www.webaim.org/howto/tables3 (This is the 
> third page in a brief and somewhat incomplete tutorial about 
> creating accessible tables).
> 
> The discovery of this bug in JAWS was quite frustrating, 
> because it meant that I couldn't even count on correct, 
> "accessible" markup to do what it is supposed to do. In fact, 
> with JAWS reading the wrong headers with the cell contents, 
> things are actually worse.
> 
> Still, this is a relatively isolated circumstance. In the 
> same tutorial (see link above), I give a couple of 
> suggestions for workarounds for this JAWS bug. If anyone else 
> has any other great ideas for workarounds, I'd love to know.
> 
> Paul Bohman
> Technology Coordinator
> WebAIM: Web Accessibility in Mind (www.webaim.org)
> Center for Persons with Disabilities (www.cpd.usu.edu)
> Utah State University (www.usu.edu)
> 
> 
> 
> ----- Original Message -----
> From: "Kynn Bartlett" <kynn-edapta@idyllmtn.com>
> To: "Brooke Dine" <dine@ncbi.nlm.nih.gov>
> Cc: "w3cwai" <w3c-wai-ig@w3.org>
> Sent: Thursday, July 12, 2001 11:02 AM
> Subject: 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 16:02:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:13:55 GMT