Creating Accessible Tables
Data Tables
Marking Up Data Tables
The purpose of data tables is to present tabular information in a grid, or matrix, and to have column or rows that show the meaning of the information in the grid. Sighted users can visually scan a table. They can quickly make visual associations between data in the table and their appropriate row and/or column headers. Someone that cannot see the table cannot make these visual associations, so proper markup must be used to make a programmatic association between elements within the table. When the proper HTML markup is in place, users of screen readers can navigate through data tables one cell at a time, and they will hear the column and row headers spoken to them.
Table Captions
Data tables very often have brief descriptive text before or after the table that indicates the content of that table. This text should be associated to its respective table using the <caption> element. The <caption> element must be the first thing after the opening <table> tag.
<table>
<caption>Shelly's Daughters</caption>
...
While it is not necessary for each table to have a caption, a caption is generally very helpful. If present, it should be associated to the table using the <caption> element.
Identify Row and Column Headers
A critical step toward creating an accessible data table is to designate row and/or column headers. In the markup, the <td> element is used for table data cells and the <th> element is used for table header cells. Going back to our original data table example, the
column headers for this table are Name, Age, and Birthday. The row headers are Jackie and Beth. Also note the associated caption.
| Name | Age | Birthday |
|---|---|---|
| Jackie | 5 | April 5 |
| Beth | 8 | January 14 |
Table headers should never be empty. This is particularly of concern for the top-left cell of some tables
Associate the Data Cells with the Appropriate Headers
Now that we've created headers, we need to associate the data cells with the appropriate headers.
The scope attribute
The scope attribute identifies whether a table header is a column header or a row header. Here is the markup for the table, using the scope attribute:
<table>
<caption>Shelly's Daughters</caption>
<tr>
<th scope="col">Name</th>
<th scope="col">Age</th>
<th scope="col">Birthday</th>
</tr>
<tr>
<th scope="row">Jackie</th>
<td>5</td>
<td>April 5</td>
</tr>
<tr>
<th scope="row">Beth</th>
<td>8</td>
<td>January 14</td>
</tr>
</table>
The scope attribute tells the browser and screen reader that everything within a column that is associated to the header with scope="col" in that column, and that a cell with scope="row" is a header for all cells in that row.
All <th> elements should generally always have a scope attribute. While screen readers may correctly guess whether a header is a column header or a row header based on the table layout, assigning a scope makes this unambiguous.
Spanned headers
Scope will apply even if the table is complex with multiple levels of headers (such as in spanned cells). The scope of a table header will apply to all cells over which that header spans.
| Name | Age | Birthday | |
|---|---|---|---|
| by birth | Jackie | 5 | April 5 |
| Beth | 8 | January 14 | |
| by marriage | Beth | 8 | January 14 |
In this example, the "by birth" row header has a scope of row, as do the headers with the names. The cell showing the age for Jackie will have 3 headers - one column header ("Age") and two row headers ("by birth" and "Jackie"). A screen reader would identify all of them, including the data cell content (e.g., it might read "by birth. Jackie. Age. 5.").
Despite being standard markup for tables for many years, some screen readers still do not fully support complex tables with spanned or multiple levels of row and/or column headers. When possible, try to 'flatten' the table and avoid spanned cells and multiple levels of header cells.
The headers and id attributes
Another way to associate data cells and headers is to use the headers and id attributes. This method is NOT generally recommended because scope is usually sufficient for most tables, even if the table is complex with multiple levels of headers.
In extremely complex tables where scope may cause table headers to apply to (or have a scope for) cells that are not to be associated to that header, then headers and id may be used. In these cases, while headers and id might make the table technically accessible, if there are multiple levels of row and/or column headers being read, it will not likely be functionally accessible or understandable to a screen reader user.
With this approach, each <th> is assigned a unique id attribute value. Then, each and every <td> cell within the table is given a headers attribute with values that match each <th> id value the cell is associated to. The values are separated by spaces and should be listed in the order in which a screen reader should read them. If using headers/id in the example above, the cell for Jackie's age might be marked up as <td headers="birth jackie age">5</td>).
Again, it should be emphasized that this method is more complex, uses much more markup (and potential to become broken), and is rarely necessary (use scope instead).
Use Proportional Sizing, Rather than Absolute Sizing
The rule that applies to layout tables also applies to data tables. Let the browser window determine the width of the table whenever possible, to reduce the horizontal scrolling required of those with low vision. If cell widths need to be defined, use relative values, such a percentages, rather than pixel values. Defined cell heights should generally be avoided so the cell can expand downward to accommodate its content - something especially useful for users with low vision that may enlarge text content.
Other table markup
Summary
The summary attribute of the <table> tag may be used to provide a summary of a data table structure (not content). Support for summary varies, but in general, it is screen reader specific (it's not accessible to anyone else) and is not well supported. Additionally, the summary attribute is not part of the HTML5 specification. In general, if a table is so complex that it needs an explanation of how it is structured, it probably is not very accessible and should probably be simplified. For these reasons, we do not recommend the use of summary. If it is used, it must never be used for layout tables.
thead, tfoot, and tbody
The thead and tfoot elements define header and footer rows for tables. They provide no accessibility functionality and are generally only of use when a long table is printed - the head and/or foot rows will repeat at the top or bottom of each printed page. Similarly, the tbody element defines the body content of a data table (meaning anything that's not a thead or tfoot). Again, this element does not provide any additional accessibility benefit, but there is no harm in using it for table styling or other reasons.