Hi,

It's a few years ago now when I tested JAWS (version 4.5 I think), and it's 
moved on since.

In that version, when in the middle of the table, IF the user gets lost, 
THEN they can press Alt+Ctrl+Num Pad 5 and it would read out headings in a 
<td> in simple tables using scope tags. It did NOT read out the headings by 
default. Thus they get to hear the table quickly, and can intervene if they 
do get lost. If you ever get the cahnce to watch a JAWS expert (i.e. someone 
with a sight impairment who's been using it for a while) at work, do take 
the opportunity - it's a revalation.

See http://www.lboro.ac.uk/computing/access/jaws.html for a quick reference 
of then Jaws keystrokes.

For a simple table like:
Day        Activity
Monday    Go to work

I'd have
<table summary="Table with two columns...">
 <caption>Activity Table</caption>
 <thead>
  <tr>
   <th scope="col" abbr="day">Day</th>
   <th scope="col" abbr="activity">Activity</th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <td>Monday</td>
   <td>Go to work</td>
 </tr>
...
 </tbody>
<thead>

OR
<table summary="...">
 <caption>Activity table</caption>
 <thead>
  <tr>
   <th scope="col" abbr="day">Day</th>
   <th scope="col" abbr="activity">Activity</th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <th scope="row" abbr="Monday">Monday</th>
   <td>Go to work</td>
  </tr>
...
 </tbody>
<thead>

All this worked fine.

It did NOT cope with axis at that release level. You do need axis for tables 
with more than two dimensions. I took the attitude that I'd code for what 
was right, and hope JAWS caught up.

I would like to know if more recent JAWS does read out table headings 
correctly with axis when the correct keystroke is pressed.

To be fair to JAWS, it's one of those chicken-and-egg things. Until suffient 
people code their tables right, what's the point of complicating your 
computer program with complex algorithms to render multi-dimensional tables 
right?


By the way, talking standards: 
http://www.w3.org/TR/UAAG10/guidelines.html#tech-table-summary Guidelines 
for user agents:
10.1 Associate table cells and headers (P1) Checkpoint 10.1
For graphical user agents that render tables, for each table cell, allow the 
user to view associated header information.
Sufficient techniques
1. The user agent may satisfy this checkpoint by allowing the user to query 
each table cell for associated header information. [which is what JAWS does, 
at least for simple 2D tables]
2. The user agent may satisfy this checkpoint by rendering the table cell 
and associated header information so they are both visible in the same 
viewport.


Regards,
Chris Beggs

----- Original Message ----- 
From: "Trevor Barton" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, April 27, 2006 12:34 PM
Subject: Best practice with table mark-up and JAWS


> Hi,
>
> I have just added JAWS to my testing suite. Not to replace testing with
> real end-users, but just to have a mechanism for testing pages with a
> screen reader. The first thing I was eager to test with it was the
> standard way we mark up data tables here. From reading the advice online I
> came up with a demanding piece of best practice advice. From my testing
> using JAWS it looks to have been all in vain. It looks like JAWS was built
> on the assumption that web page code will be (insert expletive)
> non-compliant. The never ending circle plagueing the W3C's work... with
> chinks of light when an app developer says 'lets do both/and'.
>
> I wonder if there are any users out there who know how to change the user
> preferences in JAWS to read out table AXIS, HEADERS, and ID properties, or
> whether JAWS cannot do this. (The user context help within the application
> talks about table headers as those of the rendered HTML page; physical
> headers instead of the HEADERS property.)
>
> Here's my current best practice:
>
> Say you had this table (assume there are more rows and columns than this):
>
> Time    |       Thursday
> -----------------------------------------------------------
> 15:00   |       Scanning electron microscopy
>
> In the column and row headers you might have:
>
> <th id="time" axis="time">Time</th>
> <th id="thurs" axis="day">Thursday</th>
>
> In the rows you might have:
> <th headers="time" id="three" axis="time">15:00</th>
> <td headers="thurs three"><strong><a href="tscode">Scanning electron
> microscopy</a></strong></td>
>
>
> Doing all this extra coding, it makes sense on the surface that it would
> be helpful to screen readers. 'Thursday, three o'clock, scanning electron
> microscopy' is what you are aiming for, instead of 'time thursday new line
> three o clock scanning electron microscopy', or something worse like 'new
> line blank blank blank three o clock scanning electron microscopy'.
>
> This practice is based on the following:
>
> WCAG 1.0 section 5.2:
> For data tables that have two or more logical levels of row or column
> headers, use markup to associate data cells and header cells. [Priority 1]
> For example, in HTML, use THEAD, TFOOT, and TBODY to group rows, COL and
> COLGROUP to group columns, and the "axis", "scope", and "headers"
> attributes, to describe more complex relationships among data.
>
> Doing this for the benefit of screen readers seems to be supported by some
> others out there. For example see
> http://www.mcu.org.uk/articles/tables.html (go to 'ID and Headers') "By
> giving each table heading a unique label (using the 'id' attribute) - and
> then associating each of the data cells with that label, using the
> 'header' attribute, new Web browsers can give appropriate feedback for
> those using assistive technologies."
>
> Does anyone know what those 'new Web browsers' are? I admit I was using a
> PC with IE in the testing, not Firefox, because I don't have admin rights
> to install...common desktop...usually use a Mac so don't care....but JAWS
> is only on PC...yada yada.
>
> WebAim (http://www.webaim.org/techniques/tables/2#id) suggests that just
> using 'scope' is fine for tables with one or two axes, but for any complex
> tables, ID and HEADERS should be used.
>
> That would certainly be simpler. SCOPE is easy to deploy. For ID and
> HEADERS you have to put something unique for every cell.
>
> Given that I've not been able to find a way for JAWS (one of the more
> popular screen readers) to make use of any of this extra (ID and HEADERS)
> information, is it worth doing, or is it following W3C's ideals and nobody
> else's practice?
>
>
> Many thanks,
> ______________________________
> Trevor Barton
> Web Officer
> University of Oxford
> University Offices, Wellington Square, Oxford, OX1 2JD, UK
> T: +44 (0)1865 280546
> F: +44 (0)1865 280522
> www.ox.ac.uk
>