 |
 |
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