Data Tables vs. Layout Tables
Screen readers treat data tables differently than layout tables. Layout tables are not identified and are read linearly as standard page content. Data tables, however, will be identified, the number or rows and columns read, and functionality provided for users to navigate through the table by cell.
While tables have never been intended to control layout, they often are used this way. The problem is that there is not a clear way to identify whether a table is being used for tabular data or for controlling layout. Screen readers, therefore, apply heuristics to determine the type of table encountered. The heuristics in the popular JAWS screen reader are very poor.
JAWS Behavior
UPDATE: In response to the details provided here, Freedom Scientific reports that JAWS 11.0.756 released Dec. 17, 2009 resolves many of these issues and now accounts for the presence of table headers in it’s consideration of table type.
Data tables should typically be assigned table headers (the <th> element) for all header cells. The presence of a <th> element in a table should be a dead giveaway that a table is intended for data. I’ve seen very few instances of the <th> element inappropriately used in layout tables. However, JAWS does not consider table headers or any other markup commonly used in data tables to determine the table type.
Instead, JAWS assumes the presence of a data table if it has at least 2 rows and 2 columns AND at least 4 cells in the table are between 200 and 16000 square pixels in size. 16000 square pixels is not much – a long sentence of default text or a small 200X80 pixel image.
Additionally, JAWS will treat tables with the DataTable=true or DataTable=1 attributes as data tables. Because this attribute is neither commonly used nor standards compliant, this will not be discussed as a viable solution to the problem, though it could be implemented as a ‘hack’ if need be.
This logic leaves much to be desired. It results in many data tables being incorrectly treated as layout tables, even if those data tables have appropriate header or other accessibility markup. Likewise, layout tables may be identified as data tables.
Examples
Consider the following simple table:
| Name | Age |
|---|---|
| Fred | 31 |
| Joe | 8 Note: Joe was born on February 29th of a leap year, so he really is older than Fred even though he only celebrates his birthday every 4 years. |
This is clearly a data table. Table headers and a caption have been provided. However, in JAWS this table is not read as a data table because there are only 3 cells (those in the left hand column) that are less than 16000 square pixels (at least at standard resolutions and settings). The sentence of text in the last cell makes that cell and all other cells in that column more than 16000 square pixels. JAWS users navigating this table will not get additional accessibility functionality.
Similarly, the following simple layout table which has no headers identified will be identified by JAWS as a data table simply because more than 4 cells are between 200 and 16000 square pixels in size.
 |
WebAIM Logo |
| 150X76 pixels | |
| 6kb | |
 |
WAVE Logo |
| 76X76 pixels | |
| 4kb |
To compound this issue, JAWS analyzes the rendered size of the cell only, regardless of the cell contents making it virtually impossible for developers to control JAWS behavior. This means that users who increase their font size or zoom the page contents in their browser are more likely to have data tables be interpreted as layout tables because they are more likely to have cells over 16000 square pixels. This is particularly concerning because JAWS users with low vision are very likely to have enlarged content.
Now What?
ARIA does provide some assistance. Adding role="presentation" to the table causes it to always be treated as a layout table and adding ARIA role="grid" causes any table to be treated as a data table (note that with JAWS’ updated table detection heuristics, role="grid" is likely not necessary, and it could potentially cause confusion). This is supported in JAWS 10+.
Screen readers need heuristics to handle 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 just because cells in that table happen to be big. Likewise, a layout table should not be treated as a data table just because none of the cells happen to be big. Hopefully Freedom Scientific will address this issue, though this is rather unlikely considering their responsiveness to such issues in the past (update – this issue has been at least partially resolved in JAWS 11.0.756). There’s little that developers can do about this issue. They should continue marking up data tables for accessibility as best as they can and transition away from using tables for layout. Additionally, screen reader users can use NVDA or another screen reader that handles tables appropriately.
thanks Jared for the post.
As a blind user, I find Jaws is like IE6: some things absolutely require it (especially old applications), but in the majority of cases, it should not be used. This is just a small example of the many thousands of things Jaws does wrong. I wouldn’t have a problem with web developers requiring NVDA or another screen reader that follows standards. We as blind people aren’t going to get full web accessibility until Jaws is no longer a factor. Freedom Scientific has shown, repeatedly, that they have no interest in working with standards bodies, following standards (either web standards or desktop standards like IAccessible2), or helping developers in any meaningful way. Currently, Jaws is one of the largest factors holding us back from full accessibility. We as users and concerned developers need to launch a marketing blitz similar to the one that’s made huge progress in killing off IE6. That’s the only way we’re going to see any improvement in the situation.
Great article, as usual! PS: I really like the title and graphic, too!
Great article! Very interesting post ;D
Most people who speak English but don’t know techese are going to have absolutely no idea what the hell you’re talking about! could you in English explain what your beef is? spacifically what is a lay out table? what is the difference between a lay out and data table? freedom scientific is giving this the attention it deserves which is absolutely none!
How about marking up the tables that are being used for layout with role=’presentation’. I have used this to cause JAWS to avoid reading the contents. I agree with the other commenters that it can be very difficult to work around these specific issues.
Thanks Jared, This explains an issue that we have been working on for a little while with no success. I will forward this blog post to the developers who originally sent the issue to me. I will also see if we can open a bug report with Freedom Scientific since this issue is likely to impact our case management system.
I made a minor update to the article to indicate that role=”presentation” can be used to force JAWS to treat tables as layout tables. There is also a role=”table” which should force it to treat the table as a data table, but this does not work.
@Marcus:
Tables (the table element in HTML, and its related elements) can be used for two purposes: for data tables like Jared shows in this article, and for layout, which means that you use a table like a grid and position your content in the different cells according to where you want it to be displayed. This use is bad, and developers should use CSS for handling the presentation of the markup.
There’s an article here on WebAIM which shows both types of tables: Creating Accessible Tables. Remember that even though layout tables can be made more accessible, the optimal thing to do is not use them at all for that purpose (i.e., only use them for tabular data), and go for CSS instead.
I hope this sheds some light to your doubt.
Good article as always Jared. Just a couple of questions:
* Which version of Jaws did you test with? Jaws 10 picked up your data table but inaccurately flagged your layout table as a data table.
* What heuristics would you like to see Jaws using? The tag alone wouldn’t be enough, since too many data tables don’t use these, and the SUMMARY attribute is too often used in layout tables. What heuristics is NVDA using?
Lynn-
I tested with JAWS 10. The fact that your installation identified the data table highlights the problem – that there’s no consistency. Your resolution or font size likely causes the table to render in a way that it meets the heuristics. Mine doesn’t.
I think what they have now is fairly adequate, except that any table with headers or a caption should always be treated as a data table. And instead of calculating the cell size, I think measuring the length of text in the cell would be better.
This is why developers need to code to standards and not try and pander to freedom scientific & all the different quirks it has at each version. Especially when products like Serotek’s System Access & NVDA are available at no cost (or low cost). Serotek for example has proven itself to be willing to make changes and follow standards & with the fact that they launch updates every week for their product, this could all be done relatively quickly.
On another note, Tables for layout should be relegated to the vaults of history just like frames were in the 90s. We should not encourage this or pander to it.
Brilliant post J.Smith!
Thums up for NVDA, which follows standards and presents information to users as it is meant to be. This gives a clear indication where we are headed in the future, no matter what market stats show, NVDA & SA2GO will definately be the choice for developers for screen reader testing.
I will however like to make a point that it is not currently advisible to depend on ARIA role completely for identifying data tables since many have not yet started implementing ARIA completely, it should be a combine effort of looking for caption and attribute and look for ARIA if available.
The ARIA role for data tables is actually ‘grid’ not ‘table’
http://www.w3.org/TR/wai-aria/roles#grid
Thanks James! My testing shows that JAWS will treat tables with role=”grid” as data tables. This seems to be a reasonable, though entirely unnecessary solution to this issue. I’ve updated the post to reflect this.
Freedom Scientific is reporting that table headers are now accounted for when determining the table type as of JAWS version 11.0.756 released Dec. 17th. This, of course, does not solve the problem for existing JAWS installations. My current recommendation would be to add the proper ARIA roles (grid or presentation) to tables that may be problematic to ensure proper treatment in JAWS 10+.
In my case I still se both tables on this page as data tables. I am running 11.0.756 so I’m not sure how right now this is really any better. I don’t believe that the second table here should been seen as a table, agreed?
Don-
The updates help address data tables that are treated like layout tables. I don’t think the updates change the behavior of layout tables sometimes being treated like data tables. Fortunately, this is much less problematic than users losing the ability to navigate data tables. Also, I’m not really sure what they would change to make this better.
Great post!
My only comment is in response to other comments that present NVDA as a viable screen reader alternative. The idea of NVDA is great but it lacks some important abilities – including data table functions. NVDA is only just starting to implement support for data tables on the web.
Sofia-
Thank you for the comment. I understand that full data table support is not yet there in NVDA but is coming soon. However, it already properly detects the presence of tables correctly and allows navigation to them better than JAWS (at least before 11.0.756).
Yes indeed NVDA has yet to catch up quite a bit. Only JAWS and Window-Eyes seem to read headers in complex tables when header-ids are used. Only JAWS supports the ‘scope’ attribute. Support for scope had broken in JAWS 9 and 10 and Freedom Scientific finally fixed it after my repeated emails. Then when there are form controls in a table, it is useful to be able to navigate it as a table sometimes. Now Window-Eyes does not regard a table with form controls in it as a data table. Going forward, role=presentation will help to identify layout tables. But there are a whole lot of tables out there already and going by the way tables have been used, it is not easy to distinguish layout tables from data tables without some false positives.
Sailesh
My only comment is in response to other comments that present NVDA as a viable screen reader alternative. The idea of NVDA is great but it lacks some important abilities — including data table functions. NVDA is only just starting to implement support for data tables on the web.
It’s very poor when developers are still using tables for layouts.
Is it not true that ARIA is only supported when served with the xml MIME type, which is not supported in IE6?
We really should use table only for tabular data and not for building website layout. I can remember early I also used tables, but now if I am thinking on it, it was a really bad habit. Anyway, good article.
I made a minor update to the article to indicate that role=”presentation” can be used to force JAWS to treat tables as layout tables. There is also a role=”table” which should force it to treat the table as a data table, but this does not work.