E-mail List Archives
Thread: Problem with JAWS Table Navigation?
Number of posts in this thread: 48 (In chronological order)
From: Evans, Donald (Contractor)
Date: Wed, Dec 02 2009 1:20PM
Subject: Problem with JAWS Table Navigation?
No previous message | Next message →
Can anyone explain to me why JAWS does not recognize the 3rd table in the following code as a table? The T key will not move to it, and the normal table keys will not navigate it. However, if I take out the line of text in the last TD. It works as expected?
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title> Table Test </title>
</head>
<body>
<p>
Test
</p>
<table>
<tr>
<th>test1</th>
<th>test</th>
</tr>
<tr>
<td>test data</td>
<td>test data</td>
</tr>
</table>
<table>
<tr>
<th>test2</th>
<th>test2</th>
</tr>
<tr>
<td>test data</td>
<td>test data</td>
</tr>
</table>
<table>
<tr>
<th>Title</th>
<th>Summary</th>
</tr>
<tr>
<td>strff</td>
<td>stuff</td>
</tr>
<tr>
<td>stuff</td>
<td>This MAP Learning Activities Workbook will help guide you in your development
of a dynamic and effective Mentoring Action Plan. It also offers sample Mentoring Goals and Learning Activities.
</td>
</tr>
</table>
</body>
</html>
Donald F. Evans, DeQue Systems<http://www.deque.com/>;
US Dept of Education
Email: = EMAIL ADDRESS REMOVED =
Phone: 202.453.7317
Does your website meet Section 508 Standards?
From: Jared Smith
Date: Wed, Dec 02 2009 1:58PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On Wed, Dec 2, 2009 at 1:16 PM, Evans, Donald (Contractor)
< = EMAIL ADDRESS REMOVED = > wrote:
> Can anyone explain to me why JAWS does not recognize the 3rd table in the following code as a table?
Very interesting. JAWS applies some weird heuristics to determine if a
table looks like a data table or if it looks like a layout table. The
presence of <th> should ALWAYS trigger table mode. I did some playing
around, and in this case (and probably ALL cases?), JAWS determines
that a table is a layout table if it contains more than 151 characters
in any given cell. So the 'long' text you have in the 3rd table is
throwing it off.
It also applies this wacky logic in reverse. If you remove the <th>s
from the first table, it still identifies it as a data table because
no cell has more than 151 characters.
NVDA appropriately uses the presence of headers to determine the type of table.
In other words, the presence or absence of table headers have no
impact on whether JAWS identifies a table as a data or a layout table.
It's entirely determined by the maximum amount of text in any given
cell.
Am I the only one that thinks this is totally crazy?
Jared Smith
WebAIM
From: Chris Hoffman
Date: Wed, Dec 02 2009 1:45PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On Wed, Dec 2, 2009 at 3:41 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> In other words, the presence or absence of table headers have no
> impact on whether JAWS identifies a table as a data or a layout table.
> It's entirely determined by the maximum amount of text in any given
> cell.
>
> Am I the only one that thinks this is totally crazy?
No, you aren't. What about the presence or absence of thead or tfoot?
Chris
From: Evans, Donald (Contractor)
Date: Wed, Dec 02 2009 1:50PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
Ahhh. So that somewhat explains why adding the attribute DataTable="1" to the table tag will force JAWS to recognize it as a data table. And yeah, that's pretty crazy!
From: Jared Smith
Date: Wed, Dec 02 2009 1:55PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On Wed, Dec 2, 2009 at 1:44 PM, Chris Hoffman wrote:
> No, you aren't. What about the presence or absence of thead or tfoot?
The presence of thead or tfoot has no impact on whether JAWS thinks
it's a data or a layout table. As near as I can tell, the only thing
it checks is for any cell with more than 151 characters or
DataTable="1" (which nobody uses primarily because it's not standards
compliant).
I find it interesting (in a depressing way) that we spend so much time
focusing in advanced accessibility with ARIA, etc. when we can't get
commercial AT to recognize even very basic accessibility properties in
HTML. Viva la NVDA!!!
Jared
From: Don Mauck
Date: Wed, Dec 02 2009 2:27PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
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.
From: Jared Smith
Date: Wed, Dec 02 2009 4:33PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
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
From: Geof Collis
Date: Wed, Dec 02 2009 4:45PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
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
>
From: James Nurthen
Date: Wed, Dec 02 2009 4:48PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
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 ADDRESS 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
>
From: Jared Smith
Date: Wed, Dec 02 2009 4:54PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On Wed, Dec 2, 2009 at 4:45 PM, Geof Collis < = EMAIL ADDRESS REMOVED = > wrote:
>
> Why are people still using tables for layout?
That's a very good question. But they still do, so we must deal with it.
If a layout table is falsely detected as a data table, this is
annoying. The bigger issue is when a data table is falsely interpreted
to be a layout table and all accessibility functionality is lost.
Jared
From: Jared Smith
Date: Wed, Dec 02 2009 4:57PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On Wed, Dec 2, 2009 at 4:48 PM, James Nurthen < = EMAIL ADDRESS REMOVED = > wrote:
> 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!
It's much worse than that! JAWS uses the rendered table size, so
simply increasing your font size or zooming the page can result in
data tables being interpreted as layout tables, thus they'd lose all
accessibility functionality.
Take a data table that has a sentence of text and JAWS identifies it
as a data table. Bump up the font or zoom the page a bit and it
suddenly is a layout table even if headers are in place.
Now let's all think of an audience that is quite likely to have
increased fonts or be zooming a page. Hmmm... JAWS users maybe?
Jared
From: Don Mauck
Date: Wed, Dec 02 2009 5:06PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
These rules came from the FS support staff.
From: Keith Parks
Date: Wed, Dec 02 2009 5:15PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On Dec 2, 2009, at 3:45 PM, Geof Collis wrote:
> Why are people still using tables for layout?
Even if everyone stopped building pages with layout tables tomorrow,
there would still be a huge number existing sites that, if the content
has proper structural markup, could be reasonably accessible.
Seems to me that a good tool ought to be able to deal with these
legacy sites, that may *never* be updated, in terms of page structure.
******************************
Keith Parks
Graphic Designer/Web Designer
Student Affairs Communications Services
San Diego State University
San Diego, CA 92182-7444
(619) 594-1046
mailto: = EMAIL ADDRESS REMOVED =
http://www.sa.sdsu.edu/communications
http://kparks.deviantart.com/gallery
----------------------------------------------------------
Yes We Can!*
*should not be interpreted to mean that we necessarily will
From: Geof Collis
Date: Wed, Dec 02 2009 5:42PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
Hi Jared
With all due respect, no we shouldnt' deal with it, people should
stop it, plain and simple. I rarely use table commands to navigate
web pages. I use semantic markup commands to find my way around sites.
Why should we have to deal with people's unwillingness to get with
the times. I stop usig tables in my web design 5 years ago.
Accessibility is about growth, not stagnation.
cheers
Geof
At 06:53 PM 12/2/2009, you wrote:
>On Wed, Dec 2, 2009 at 4:45 PM, Geof Collis < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > Why are people still using tables for layout?
>
>That's a very good question. But they still do, so we must deal with it.
>
>If a layout table is falsely detected as a data table, this is
>annoying. The bigger issue is when a data table is falsely interpreted
>to be a layout table and all accessibility functionality is lost.
>
>Jared
>
From: Geof Collis
Date: Wed, Dec 02 2009 5:48PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
Hi Keith
Given the growth of the Mobile web, how will these sites fair?
cheers
Geof
At 07:15 PM 12/2/2009, you wrote:
>On Dec 2, 2009, at 3:45 PM, Geof Collis wrote:
>
> > Why are people still using tables for layout?
>
>Even if everyone stopped building pages with layout tables tomorrow,
>there would still be a huge number existing sites that, if the content
>has proper structural markup, could be reasonably accessible.
>
>Seems to me that a good tool ought to be able to deal with these
>legacy sites, that may *never* be updated, in terms of page structure.
>
>******************************
>Keith Parks
>Graphic Designer/Web Designer
>Student Affairs Communications Services
>San Diego State University
>San Diego, CA 92182-7444
>(619) 594-1046
>mailto: = EMAIL ADDRESS REMOVED =
>http://www.sa.sdsu.edu/communications
>
>http://kparks.deviantart.com/gallery
>----------------------------------------------------------
>
>Yes We Can!*
>
>*should not be interpreted to mean that we necessarily will
>
>
From: Jared Smith
Date: Wed, Dec 02 2009 5:54PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On Wed, Dec 2, 2009 at 5:42 PM, Geof Collis < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Jared
> With all due respect, no we shouldnt' deal with it, people should
> stop it, plain and simple. I rarely use table commands to navigate
> web pages. I use semantic markup commands to find my way around sites.
I absolutely agree. My comments were in relation to assistive
technology support. While there's little excuse for developers using
layout tables, assistive technology must "deal with" this for some
time to come. This thread is pointing out that JAWS has very poor
behavior in determining data vs. layout tables and that is very
concerning. If I had it my way, all layout tables would disappear and
this would all be a non-issue.
Jared
From: Geof Collis
Date: Wed, Dec 02 2009 6:06PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
Hi Jared
Agreed! Problem is, do we need companies like Freedom Scientific
worrying about this kind of thing wehn developers should get with
the times so they can address other more pressing issues? Seems more
like a retrofitting issue.
cheers
Geof
At 07:52 PM 12/2/2009, you wrote:
>On Wed, Dec 2, 2009 at 5:42 PM, Geof Collis < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi Jared
> > With all due respect, no we shouldnt' deal with it, people should
> > stop it, plain and simple. I rarely use table commands to navigate
> > web pages. I use semantic markup commands to find my way around sites.
>
>I absolutely agree. My comments were in relation to assistive
>technology support. While there's little excuse for developers using
>layout tables, assistive technology must "deal with" this for some
>time to come. This thread is pointing out that JAWS has very poor
>behavior in determining data vs. layout tables and that is very
>concerning. If I had it my way, all layout tables would disappear and
>this would all be a non-issue.
>
>Jared
>
From: Webb, KerryA
Date: Wed, Dec 02 2009 6:12PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
>
> Hi Jared
>
> Agreed! Problem is, do we need companies like Freedom Scientific
> worrying about this kind of thing wehn developers should get with
> the times so they can address other more pressing issues? Seems more
> like a retrofitting issue.
>
Yes, we do. The sites that use tables for formatting aren't going to
change in a hurry, so the tools must take account of this.
Kerry
-----------------------------------------------------------------------
This email, and any attachments, may be confidential and also privileged. If you are not the intended recipient, please notify the sender and delete all copies of this transmission along with any attachments immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person.
-----------------------------------------------------------------------
From: Geof Collis
Date: Wed, Dec 02 2009 6:48PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
Listening to the tone of this thread Sounds like they're not going to
change, so as usual it is the/us " Tools" that will always play
catchup, just because developers
At 08:10 PM 12/2/2009, you wrote:
> >
> > Hi Jared
> >
> > Agreed! Problem is, do we need companies like Freedom Scientific
> > worrying about this kind of thing wehn developers should get with
> > the times so they can address other more pressing issues? Seems more
> > like a retrofitting issue.
> >
>
>Yes, we do. The sites that use tables for formatting aren't going to
>change in a hurry, so the tools must take account of this.
>
>Kerry
>
>-----------------------------------------------------------------------
>This email, and any attachments, may be confidential and also
>privileged. If you are not the intended recipient, please notify the
>sender and delete all copies of this transmission along with any
>attachments immediately. You should not copy or use it for any
>purpose, nor disclose its contents to any other person.
>-----------------------------------------------------------------------
>
From: Jared Smith
Date: Wed, Dec 02 2009 9:18PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
I've put together some basic examples and some additional thoughts on
our blog at http://webaim.org/blog/jaws-ate-my-tables/
Jared Smith
WebAIM
From: Bevi Chagnon | PubCom
Date: Wed, Dec 02 2009 9:36PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
Jared, thanks for this article. I'm forwarding the link to my local
webmasters list.
One question:
In the paragraph just before the first subhead "Examples", you wrote...
"This logic leaves much to be desired. It results in many data tables being
incorrectly treated as data tables, even if those data tables have
appropriate header or other accessibility markup. Likewise, layout tables
may be identified as data tables."
Did you mean to say "It results in many data tables being incorrectly
treated as LAYOUT tables?"
--Bevi Chagnon
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . .
Bevi Chagnon | = EMAIL ADDRESS REMOVED = | www.PubCom.com
Consultants + Trainers + Designers | for print, web, marketing, Acrobat, &
508
PublishingDC Group Co-Moderator |
http://groups.yahoo.com/group/PublishingDC
Bevi blogs on Facebook |
www.facebook.com/pages/Takoma-Park-MD/PubCom/139231069223
. . . . . . . . . . . . . . . . . . . . . . . . . .
. .
From: Jared Smith
Date: Wed, Dec 02 2009 9:51PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On Wed, Dec 2, 2009 at 9:34 PM, Bevi Chagnon | PubCom wrote:
> Did you mean to say "It results in many data tables being incorrectly
> treated as LAYOUT tables?"
Yep! Nice catch! And thanks for the heads up. It's been corrected.
Jared
From: Chris Hoffman
Date: Wed, Dec 02 2009 10:42PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
Should we start using the datatable attribute? It won't validate, as
mentioned, but it may be the most direct way around this nonsense.
Chris
On Wed, Dec 2, 2009 at 11:51 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> On Wed, Dec 2, 2009 at 9:34 PM, Bevi Chagnon | PubCom wrote:
>
>> Did you mean to say "It results in many data tables being incorrectly
>> treated as LAYOUT tables?"
>
> Yep! Nice catch! And thanks for the heads up. It's been corrected.
>
> Jared
>
From: Evans, Donald (Contractor)
Date: Thu, Dec 03 2009 5:54AM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
Dito Jared. Thanks!
From: Evans, Donald (Contractor)
Date: Thu, Dec 03 2009 5:57AM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
I'm going to start giving the advise to use DataTable = 1 to our developers.
From: Sam S
Date: Thu, Dec 03 2009 6:30AM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
You can turn Layout Tables to "Off" in JAWS Options dialog using command
Insert+V. This should enable reading of all tables: layout as well as data
tables. You can enable this for specific websites by using JAWS personalized
settings feature by using command INSERT+SHIFT+V .
Not the best solution but this will enable that JAWS reads all table
information on certain websites.
On Thu, Dec 3, 2009 at 6:21 PM, Evans, Donald (Contractor) <
= EMAIL ADDRESS REMOVED = > wrote:
> Dito Jared. Thanks!
>
>
From: Jared Smith
Date: Thu, Dec 03 2009 8:51AM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On Thu, Dec 3, 2009 at 5:52 AM, Evans, Donald (Contractor)
< = EMAIL ADDRESS REMOVED = > wrote:
> I'm going to start giving the advise to use DataTable = 1 to our developers.
Myself, I'm pretty uncomfortable with this approach. It's totally
arbitrary and there's nothing keeping JAWS from ignoring this
attribute in the future because it's not standards compliant.
Remember, this issue only affects data tables that don't have at least
4 cells that are less than 16000 pixels. As such, most data tables are
not affected unless nearly ALL of the cells are over that size.
Perhaps it could be implemented for these cases. There is an ARIA role
of table that should force JAWS to treat any table like a data table,
but this doesn't seem to work, at least in JAWS 10. Can somebody test
in JAWS 11?
In the opposite case, where layout tables are identified as data
tables because the cells are not large, you can add
role="presentation" to the layout table to have it not be identified
(though the contents of the table are still read as they should be).
This seems to work quite well in JAWS. Definitely use
role="presentation" over DataTable=0.
Jared
From: Moore,Michael (DARS)
Date: Thu, Dec 03 2009 9:57AM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
Jared,
We have identified another work-around and tested it in JAWS 9, 10 and 11. If the user turns layout tables on, rather than off as was suggested earlier, table reading commands and navigation will work on properly marked up tables that are ignored by JAWS because of the cell size issue. It may be possible to cue JAWS users by adding a single pixel gif with alt="JAWS users can repair table reading for this table by enabling layout tables in the verbosity dialog" This gif could be placed in the caption or the first header cell.
Of course they will want to turn off layout tables after they have navigated the table.
In the mean time if anyone would like to report this bug to Freedom Scientific, the number for tech support is (727) 803-8600 or email at = EMAIL ADDRESS REMOVED = .
Mike Moore
From: Margit Link-Rodrigue
Date: Thu, Dec 03 2009 10:03AM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
Except that NVDA doesn't handle data tables well at all. There is no way to
announce the header text for a cell from within that cell. Isn't this one of
the more crucial features for navigating data tables?
On Wed, Dec 2, 2009 at 2:54 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> On Wed, Dec 2, 2009 at 1:44 PM, Chris Hoffman wrote:
>
> I find it interesting (in a depressing way) that we spend so much time
> focusing in advanced accessibility with ARIA, etc. when we can't get
> commercial AT to recognize even very basic accessibility properties in
> HTML. Viva la NVDA!!!
>
> Jared
>
From: Evans, Donald (Contractor)
Date: Thu, Dec 03 2009 10:06AM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On the particuliar page that I am dealing with it is completely laid out with tables. There are a total of eight tables on the page. Five are layout and three are data. One contains text in excess of 150 charaters.
I am not sure changing the JAWS configuration is the best user experience in this case. Thoughts?
From: Moore,Michael (DARS)
Date: Thu, Dec 03 2009 10:27AM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
From: Don Mauck
Date: Thu, Dec 03 2009 12:21PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
I thought that the cyntax was LayoutTables = '0', am I mistaken?
From: Don Mauck
Date: Thu, Dec 03 2009 12:24PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
Whether they be data or layout tables, anouncing headers will always be crutial. I just can't think of any good reason that we should ever have layout tables.
From: Evans, Donald (Contractor)
Date: Thu, Dec 03 2009 12:39PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
I agree there is no good reason to use layout tables. But what I can not understand is why JAWS would not announce a TH tag even when it is there just because their code decides it's not a data table. The tag means Table Header and should be announced as one. I M H O
From: Moore,Michael (DARS)
Date: Thu, Dec 03 2009 12:48PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
Don Mauck wrote:
Whether they be data or layout tables, announcing headers will always be crucial. I just can't think of any good reason that we should ever have layout tables.
Mike replies:
Whether we like them or not they are out there and will be for the foreseeable future. Many web based collaboration, content management, and database application platforms are based on table layouts, for example Oracle's PeopleSoft, and Microsoft's SharePoint. Some of these platforms severely limit the ability of the developer or the designer to control the structure of the generated html. The two examples above have done quite a bit to improve accessibility in their more recent releases but the table layouts are still there. From the standpoint of the screen reader user, if data tables and layout tables are coded correctly, and interpreted correctly by the screen reader, the use of a layout table does not impact accessibility. That being said, if I have control over layout I will use CSS and save the tables for the data.
On the flip side of the everything goes in a table database application system is the nothing goes in a table system like Crystal Reports. All of the "table cells" are divs and they are stacked up like blocks. This presents a far more serious problem for screen reader users, particularly if the blocks form a complex table. The best option with this output is usually to export the output to Excel and then clean it up.
Mike Moore
(512) 424-4159
From: Travis Roth
Date: Thu, Dec 03 2009 1:42PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
An easier approach to the invisible graphic may be to include the summary
attribute or a caption in the data table. In my observations, JAWS wil treat
any table with a Summary attribute as a data table. (Note the summary
attribute does need to be set to something other than null.)
For the necessary layout tables, the ARIA markup role=presentation may be
the best in the long-term as ARIA support improves?...
From: Moore,Michael (DARS)
Date: Thu, Dec 03 2009 2:09PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
We tested adding the summary attribute and JAWS still ignored the table unless layout tables is turned on. The caption element does not seem to have an effect either. One interesting new note, when I just went back to verify this I notice that, for my installation of JFW10 anyway, leaving the browser and returning results in JAWS toggling layout tables back off. Oh well back to the lab - perhaps more stuff to report to Freedom.
Mike Moore
From: Jared Smith
Date: Thu, Dec 03 2009 2:15PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On Thu, Dec 3, 2009 at 2:08 PM, Moore,Michael (DARS) wrote:
> We tested adding the summary attribute and JAWS still ignored
> the table unless layout tables is turned on. The caption element
> does not seem to have an effect either.
This is precisely what I've found as well. Summary and caption have no
affect on determining the type of table.
> One interesting new note, when I just went back to verify this I
> notice that, for my installation of JFW10 anyway, leaving the
> browser and returning results in JAWS toggling layout tables
> back off.
I don't experience this behavior, not that it would really make much
of a difference for anybody anyway.
Jared
From: Keith Parks
Date: Thu, Dec 03 2009 4:42PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On Dec 3, 2009, at 11:16 AM, Don Mauck wrote:
> I just can't think of any good reason that we should ever have
> layout tables.
html e-mail?
(Thanks again, Microsoft, for such poor support for css in the latest
version of Outlook.)
******************************
Keith Parks
Graphic Designer/Web Designer
Student Affairs Communications Services
San Diego State University
San Diego, CA 92182-7444
(619) 594-1046
mailto: = EMAIL ADDRESS REMOVED =
http://www.sa.sdsu.edu/communications
http://kparks.deviantart.com/gallery
----------------------------------------------------------
(Objects on your screen may be closer than they appear)
From: Birkir Gunnarsson
Date: Thu, Dec 03 2009 7:45PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
Keith
I just got around to testing your html code with my Jaws v9.0. It recognizes
the table and the table navigation in the third table is perfect.
What versin of Jaws are you testing with and what, exactly, is not working?
I amcertainly not claiming things could not have broken between Jaws v9 and
11, there's a reason I have not splurged on the upgrade, namely I have had
very little reason to do so as newer versions of Jaws have not offered
anything of interst to me, until I upgrade to Windows 7.
Thanks
-B
From: Moore,Michael (DARS)
Date: Fri, Dec 04 2009 8:09AM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On Dec 3, 2009, at 11:16 AM, Don Mauck wrote:
> I just can't think of any good reason that we should ever have
> layout tables.
Kieth Parks Replied:
html e-mail?
(Thanks again, Microsoft, for such poor support for css in the latest
version of Outlook.)
Mike says
Even more fun is that in Outlook 2007 JAWS users cannot navigate layout tables. I have been told that this because MS is using the MS Word html rendering engine. To read an html email that is contained within a layout table the JAWS user must open the email in their browser.
From: Moore,Michael (DARS)
Date: Fri, Dec 04 2009 8:15AM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
Birkir,
To see the problem make sure that you have turned off layout tables in the verbosity settings. If JAWS is set to announce layout tables everything works fine. We verified this on multiple systems running JFW 9, 10, and 11.
Mike Moore
(512) 424-4159
From: Keith Parks
Date: Fri, Dec 04 2009 9:15AM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On Dec 3, 2009, at 6:42 PM, Birkir Gunnarsson wrote:
> Keith
>
> I just got around to testing your html code with my Jaws v9.0.
Not my post originally, but hopefully Donald Evans is still following
the thread.
******************************
Keith Parks
Graphic Designer/Web Designer
Student Affairs Communications Services
San Diego State University
San Diego, CA 92182-7444
(619) 594-1046
mailto: = EMAIL ADDRESS REMOVED =
http://www.sa.sdsu.edu/communications
http://kparks.deviantart.com/gallery
----------------------------------------------------------
Putting the "no" in "Innovation" since 1988.
From: Don Mauck
Date: Fri, Dec 04 2009 9:18AM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
This is all true, I can attest to such behavior.
Regards,
Don
Oracle
Don Mauck | Accessibility Evangelist
Oracle Corporate Architecture Group
7700 Technology Way
Denver CO 80237
Phone (303) 334-4184
Email = EMAIL ADDRESS REMOVED =
Green Oracle
Oracle is committed to developing practices and products that help protect the environment
From: Evans, Donald (Contractor)
Date: Fri, Dec 04 2009 9:21AM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On Dec 3, 2009, at 6:42 PM, Birkir Gunnarsson wrote:
> Keith
>
> I just got around to testing your html code with my Jaws v9.0.
Not my post originally, but hopefully Donald Evans is still following
the thread.
Yes I am, with great interest. Thanks for all the comments.
---don
From: Jared Smith
Date: Mon, Dec 21 2009 3:18PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
On Wed, Dec 2, 2009 at 9:18 PM, Jared Smith wrote:
> I've put together some basic examples and some additional thoughts on
> our blog at http://webaim.org/blog/jaws-ate-my-tables/
I thought I'd post a quick update on the JAWS and data tables issue.
Apparently the newest version of JAWS (version 11.0.756 released Dec.
17th) has improved logic for handling data tables that have table
headers (<th> elements). Can anybody verify this? You could try with
the examples in the article at
http://webaim.org/blog/jaws-ate-my-tables/
If this works, this is excellent news - and shows that Freedom
Scientific was responsive to the stink we made about this issue.
Also, James Craig also pointed out that role="grid" is the proper ARIA
role for data tables. In my testing, adding <table role="grid"> to
data tables caused JAWS 10+ to always treat them as data tables. As
noted previously, role="presentation" causes them to always be treated
as layout tables. ARIA to the rescue!
The blog posting above has been updated to reflect these developments.
Jared Smith
WebAIM
From: Tim Harshbarger
Date: Mon, Dec 21 2009 3:39PM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | Next message →
Jared,
I was just able to try out the examples using JAWS 11 (756) with both IE7 and FF3.5.4. JAWS was able to recognize the tables. Unfortunately, at the moment, I don't have access to additional browsers or browser versions to test further.
Tim
From: Moore,Michael (DARS)
Date: Tue, Dec 29 2009 9:06AM
Subject: Re: Problem with JAWS Table Navigation?
← Previous message | No next message
Well Jared,
It would appear that they are making some progress. JAWS is now announcing both tables and providing access to the headers in the data table. Unfortunately it does not ignore the layout table regardless of the verbosity settings. I prefer this error to the original. At least you always have access to the headers. We will continue to work with Freedom from our end.
Mike Moore
(512) 424-4159