Table Techniques to Avoid

Executive Summary

This document assumes that you have read and understand the Tables page.

Inaccessible tables are often the result of making them too complex, for example by trying to accomplish too much with one table or by making grouping choices for visual simplicity. The unique identifier for a single row should be entirely in the first column. Cells should not be merged to better visually group parts of the data. Row numbers are often useful, but only very rarely should they be used as a row heading. Nested (embedded) tables should never be used.

Covered in this Tutorial:

• Introduction
• Poor Table Structures
  • Multiple Headings on a Row or Column
  • Multi-Cell (Merged) Headings
  • Nested Tables
• Row Numbers
• Splitting Tables to Make them Simple

Introduction

Bad tables come in many flavors but generally they boil down to being structured more complexly than necessary. This part of the Table Tutorials concentrates on examining a few examples of poorly structured tables and provides some suggestions on fixing the problems or avoiding them in the first place.

Poor Table Structures

Multiple Headings on a Column or Row

The below table requires the first two columns to provide complete row heading information to differentiate for each row, the first column alone would not be sufficient. E.g., a screen reader properly reading the below where "Vehicle Type" and "Year Make Model" were identified as row headings would repeat "Vehicle Type" data along with "Year Make Model" when reading down the "0-60 MPH Time (Seconds)" and "Fuel Efficiency (MPG)" columns.

Table 1: BAD EXAMPLE Complex Table Multiple Headings on a Row

In some cases, it may seem desirable to have multiple header columns (or rows). (see Table 1) In Table 1, if both "Vehicle Type" and "Year Make Model" are row headings, then when switching from row 2 to row 3 in the Fuel Efficiency Column a screen reader will ideally read "Car 2008 VW Rabbit 29", and if moving from row 4 to row 5 in the same column would ideally read "SUV 2011 Jeep Compass 32". This is not consistent across all document types, some screen reader/document type configurations may only read the first header (Car/SUV) and not read the second. For this particular table a possible fix is to simply switch the order of the first 2 columns thus guaranteeing that the first column "Year Make Model" contains unique row identifying information.

Multi-Cell Headings

Table 2 below shows a row-span style of multi-cell or "merged" headings that visually group data rows; "Vehicle Types." "Car" spans 3 rows. (On the Tables page Table 2 showed the same information but laid out "Car" as a subheading spanning all 5 columns.)

Table 2: BAD EXAMPLE Multi-Cell Headings

When having multiple headings on a column or row, it is often visually desirable to have the redundant header shared across multiple cells. In Table 2, if the first two columns, "Vehicle Type" and "Year Make Model," are row headings, then when switching from "Data Row #" 2 to "Data Row #" 3 in the "Fuel Efficiency" column a screen reader might ideally read "1999 Plymouth Neon 24" because it is still in the context of "Cars," but if moving from "Data Row #" 3 to "Data Row #" 4 in the same column would ideally read "SUV 2011 Jeep Compass 32". This type of narration is ideal, but not consistent across all browsers, programs and screen readers. Some screen readers may repeat only the "Car" or "SUV" header for each row movement which would not uniquely identify the row. This example would not work with Word and NVDA in an accessible manner. (Audio File: NVDA screen reader reading Table 2 in Microsoft Word.)

Nested Tables Should Never be Used

Table 3: BAD EXAMPLE Embedded Table

When a table is embedded inside another table (see Table 3), screen readers (and many people) are unable to parse the context of each cell. This is confusing and should never be used. (Audio File: NVDA screen reader reading Table 3 in HTML.)

Row Numbers

Note also that in Table 2 a "unique" identifier for each row has been added as the "Data Row #" column. While unique and often handy as a quick reference or useful for computing group sizes the row number conveys no meaning and would not be suitable as a first column in the table hence it has been put at the end.

Splitting Tables to Make them Simple

Most complex tables can be split into multiple tables to make them simple. For instance, Table 2 above or Table 2 on the Tables page could be split to display in two simple tables like Table 3 on the Tables page and Table 4 below. (Audio File: NVDA screen reader reading previous page Tables 3 and Table 4 below in Microsoft Word.)

Table 4: GOOD EXAMPLE Simple Table instead of Complex Table - SUVs