E-mail List Archives
Re: Problem with JAWS Table Navigation?
From: James Nurthen
Date: Dec 2, 2009 4:48PM
- Next message: Jared Smith: "Re: Problem with JAWS Table Navigation?"
- Previous message: Geof Collis: "Re: Problem with JAWS Table Navigation?"
- Next message in Thread: Jared Smith: "Re: Problem with JAWS Table Navigation?"
- Previous message in Thread: Geof Collis: "Re: Problem with JAWS Table Navigation?"
- View all messages in this Thread
These "rules" also give the absurd situation where a table can be a
layout table under one screen resolution and a data table under
another!
2009/12/2 Jared Smith < <EMAIL REMOVED> >:
> On Wed, Dec 2, 2009 at 2:25 PM, Don Mauck wrote:
>> And it seems to contradict the rules they gave us a little over 1 year ago for determining a data table:
>>
>> 1. it has at least 2 valid data rrows
>> 1.1 a valid data row contains at minimum 2 columns
>> 1.2. at least 4 cells in the table fall within a given size (between 200 and 16000 square
>> pixels)
>> 2.1 if the attribute datatable=TRUE or datatable=1 its a data table.
>
> Where did you get these 'rules'? I've never seen them before. Any
> additional details?
>
> Actually, these rules are accurate, I think. I'll try to explain this
> as best as I can - it's a bit mind blowing.
>
> - JAWS analyzes the size of the table cells, not the amount of text
> within the cell (though these are naturally related). 16000 square
> pixels (this isn't very big - a couple short sentences of default text
> or a small 200X80 pixel image) is the threshold. I'll call anything
> bigger than this, a "big" cell.
>
> - A cell can be "big" even if it has one character with a very large
> margin or padding.
>
> - A cell can be "big" (>16000 square pixels) because the contents of
> another cell in its row or column is tall or wide. An empty cell can
> be "big". It has nothing to do with the contents or markup of the cell
> - only its dimensions.
>
> - If any cell within the table is "big", JAWS thinks it's a layout
> table, regardless of whether table headers or any other data table
> markup is applied. However, if there are at least 4 cells within that
> table that are NOT "big", then it thinks it's a data table - even if
> no data table markup is applied. So looking at the original poster's
> example - the three cells in the first column are NOT big, but all
> three cells in the 2nd column ARE big because the large amounts of
> text in one of those cells (which makes the other two cells wide
> enough to pass the threshold). This results in only 3 small cells,
> thus JAWS treats it as a layout table.
>
> - If no cell is big, then it's always a data table so long as there
> are at least 2 row and 2 columns - again, regardless of presence or
> absence of table headers.
>
> I can understand the need for some heuristics for better handling
> tables that are not coded with accessibility in mind, but no screen
> reader should EVER treat a table with proper header markup as a layout
> table - especially because a cell just happens to be big. Likewise, a
> layout table should not be treated as a data table, just because more
> than 3 cells happen to be small.
>
> For those that don't understand, this is a significant issue because
> screen readers treat layout and data tables significantly different.
> Layout tables are essentially ignored and read as flat content. Data
> tables are identified and can be navigated.
>
> Jared Smith
> WebAIM
>
- Next message: Jared Smith: "Re: Problem with JAWS Table Navigation?"
- Previous message: Geof Collis: "Re: Problem with JAWS Table Navigation?"
- Next message in Thread: Jared Smith: "Re: Problem with JAWS Table Navigation?"
- Previous message in Thread: Geof Collis: "Re: Problem with JAWS Table Navigation?"
- View all messages in this Thread