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.
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.
Consider the following simple table:
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.
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.
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.