- From: Jim Thatcher <jim@jimthatcher.com>
- Date: Thu, 17 Feb 2005 10:17:45 -0600
- To: "'James Craig'" <wai-ig@cookiecrook.com>, "'wai-ig list'" <w3c-wai-ig@w3.org>
- Cc: "'William R Williams'" <wrwilliams@fs.fed.us>
This (http://tinyurl.com/3tx3q) is a wonderful example of a complex table and it is remarkably well coded - as far as JAWS is concerned. I see one place which I would call a mistake: the left hand "Subtotal" column heading should have a headers attribute that points to the section headings, just like those cells immediately above it, so for the first one, you would hear with JAWS: "Fire & Aviation Management, Subtotal". The way it is marked up, all JAWS announces is "subtotal". Other than that omission, JAWS reads this table perfectly. That amazes me; I have assumed up until now, that that you should use TH (with/without scope) OR use headers/id markup, but not both. This uses both and it works well - for JAWS. What this example led me to understand is that markup must be present that specifies the heading cells of every data cell under the following conditions: 1) When a cell in row r and column c does NOT have a headers attribute, the headings for that cell consist of all cells in row r marked as TH and scope=row; and all cells in column c marked TH and scope=col. HPR and Window-Eyes do not respect this "all cells" and only take the closest cell; I think that is the AT problem. 2) Use the headers attribute with a string (blank separated) of id's of heading cells. If this is technique is used on a data cell, all heading cells must be specified and technique 1) does not come into play. In this interpretation, the headers attribute has two functions, a) to point to heading cells that are not in the same row or column as the data, OR, to override the use TH's in the same row and column. Even though JAWS reads the row headings automatically (because they are in column 1), I think this sample table should have TH, scope=row, on all the cells in the first column (style as want). This requirement is especially clear when checking the table with HPR. If there is any data table markup present (TH or headers) then HPR ONLY reads those cells so indicated. So it reads none of the row headings EXCEPT subtotal! HPR also only reads one row of column headers; that is a weakness of the AT. Window-Eyes does worse; the full-spanning TH's like "Fire & Aviation Management" are taken as the column headings even though they have no scope attribute. What should AT do: the screen readers I have checked don't all do it this way, but what I recommend is that they speak all heading cells that change as you move from one cell to the next and provide a key to announce all headings, not just the ones that change. If there are NO headings marked up for a given data cell; then assume cells in the first row and first column are headings. Interesting table. Jim Accessibility Consulting: http://jimthatcher.com/ 512-306-0931 -----Original Message----- From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On Behalf Of James Craig Sent: Thursday, February 17, 2005 12:27 AM To: wai-ig list Subject: Re: looking for an accessible data table: Patrick H. Lauke wrote: > Access Systems wrote: >> no and it is because (at least in Linux/LYNX)... > > haven't looked too hard at that page's markup, but assuming that it is > correct (properly defined headings, scope, etc), is the problem you're > describing not one of the user agent (in this case lynx) rather than > the page author? I think you've nailed it Patrick; that's why I asked what user agent Bob was using when he experienced the problem. Now that we know it's Lynx, I'm not surprised he had trouble with a data table. To follow on the 'correct markup' comment, he uses a technique I haven't seen before. Scope is used appropriately for most of the cells, and headers/ID is added on a few of the cells. I've only used these techniques independently (either all scope, or all headers/ID) but not both combined. I'm on a Mac at home and haven't had a chance to test this at work yet, but I'd be curious to know if screen readers handled this technique consistently. Here's that table again for reference. <http://www.fs.fed.us/r5/business-plans/sequoia/financials/summary- table.html> James
Received on Thursday, 17 February 2005 16:18:03 UTC