E-mail List Archives
Re: Problem with JAWS Table Navigation?
From: Geof Collis
Date: Dec 2, 2009 4:45PM
- Next message: James Nurthen: "Re: Problem with JAWS Table Navigation?"
- Previous message: Jared Smith: "Re: Problem with JAWS Table Navigation?"
- Next message in Thread: James Nurthen: "Re: Problem with JAWS Table Navigation?"
- Previous message in Thread: Jared Smith: "Re: Problem with JAWS Table Navigation?"
- View all messages in this Thread
Why are people still using tables for layout?
cheers
Geof
At 06:31 PM 12/2/2009, you wrote:
>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: James Nurthen: "Re: Problem with JAWS Table Navigation?"
- Previous message: Jared Smith: "Re: Problem with JAWS Table Navigation?"
- Next message in Thread: James Nurthen: "Re: Problem with JAWS Table Navigation?"
- Previous message in Thread: Jared Smith: "Re: Problem with JAWS Table Navigation?"
- View all messages in this Thread