RE : w3c - Scope attribute in Table tag

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 UTC