Proper tagging and description of data tables simplifies navigation and understanding for users who cannot see the data or need additional help understanding it.
- Ensure all tabular data is marked up using table tags. [[WCAG-1.3.1]]
- Provide a title in the
- Provide a summary that describes the structure of complex tables. [[WCAG-1.3.1]]
- Ensure the summary and caption do not repeat the same text. [[WCAG-1.3.1]]
- Identify the scope of header cells. [[WCAG-1.3.1]]
- Provide abbreviations for long headers.
Frequently Asked Questions
- Can I use pictures of tables?
Although table rendering is still problematic in ebooks, including images of tables instead of the actual data takes the content away from anyone who cannot see it.
Tables are a problem that still need solving in user agents, as most user agents aren't able to provide extended horizontal or vertical scrolling to facilitate rendering. As a result, large tables get rendered in the available space – leaving rows and columns to spill across page views – compromising the quality of the ebook for sighted users.
If you are going to include an image of a table, consider providing a link to a file containing the table markup. Users with text-to-speech playback available will be able to navigate the markup regardless of the rendering quality.
Some user agents render pop-out content in browser windows, which can also improve reading for sighted users unable to read images that render too small or blow out of the viewport.
See also this CSS-Tricks article on responsive tables for an alternate approach to visual table rendering based on the available screen size.
When tables are not structured accessibly, the data they contain can quickly become a meaningless sea of numbers, facts and figures to someone moving through them a cell at a time. Users who cannot see the table cannot use visual cheats like checking the alignment and scanning back to the top headers to orient themselves as they go. Equivalent information needs to be encoded into the table to facilitate comprehension.
Using HTML table elements to markup up tabular data ensures that users of assistive technologies are able to move by row and column through the data. It also provides them the context they need to understand the data they encounter.
Using tables for layout purposes is no longer valid per the HTML specification. Refer to the Layout Tables page for further discussion.
The following subsections describe the basic practices essential to making any table accessible. More complex issues are described separately in the knowledge base (refer to the related topics menu).
One of the primary aids for table navigation is the proper use of headers. Correctly identified and linked headers provide helpful context as users navigate the data points.
A column or row header is identified using the
th element. Data cells are identified
A common bad practice is to style
td elements to look like headers (e.g., by bolding
the text and adding background shading). Unless a
th element is used, assistive
technologies will not recognize the cell as a header and will not be able to announce the
header to users as they navigate through the data.
The simplest kinds of tables contain a single header for each column or row (see examples 1 and 2). When the data in such tables is self-describing and/or the table is not very large, it is not necessary to identify the headers any further. Users will be able to understand the data.
As soon as there is any complexity, such as multiple headings or many rows of data, it is necessary
to identify the "scope" of the headings. Adding a
scope attribute tells assistive
technologies whether the header applies to the current column or row. The attribute can also be used
to apply headers to multiple columns or rows.
For more information about the
scope attribute, refer to the Headers Scope page.
In some cases, tables will have complex headers for which a simple scope declaration is not
sufficient. For example, when a header for cells is not in the same column or row. In these
headers attribute allows the individual cells that comprise the header
to be identified. The attribute contains a list of one or more references to the IDs of the
header cells that apply.
For more information about the
headers attribute, refer to the Complex Headers page.
Tables can be structured to better represent the purpose of sets of rows using the
thead (table header),
tbody (table body), and
(table footer) elements.
A table can only have one
thead element, and it must be the first row-containing
element of the table. Although adding a
thead element to group the header rows
is a good semantic markup practice, the element does not affect the accessibility of tables.
It is primarily included for usability reasons. For example, the rows in a
are often scripted to remain static while a table is scrolled. The
thead is also
used by browsers to repeat the headings when printing a table (i.e., when a table is split
across print pages).
After the header can come one or more
tbody elements. Each
represents one section of a table. Using multiple
tbody elements allows each
section to have unique headers, for example. This practice can improve the readability of
these kinds of tables, so is beneficial to the accessiblity.
Finally, a table can have a single
tfoot element at the end. The
element is where column summaries are expressed. Using a
tfoot allows users to
find this information without having to navigate through every row. It is not the location for
placing extraneous content like footnotes (see example 4).
When a table header is more than a few words long, having it repeated for every data cell can
slow down users. To avoid these lengthy repetitions, it is possible to assign an shorter
header using the
<th … abbr="Total insurance"> Total insurance coverage cost on per annum basis </th> <th … abbr="Total interest"> Total interest payments for the covered period </th>
The abbreviated title will be used in place of the full header when announcing the cells beneath it.
Support for the
abbr attribute is inconsistent. NVDA does not support the
attribute, but other assistive technologies like Jaws and Voiceover do.
Captions and Summaries
In order to help users understand the purpose of tables and the ordering of their content, it is necessary to add captions and summaries.
A caption is the equivalent of a title for a table. It can be provided in the dedicated
caption element that tables can contain, or it can be expressed through other
means, such as a figure caption. More information about captions and how to mark them up
is provided in the Table Captions page.
A summary provides a description of the structure of a table. It helps users who cannot see the content or have difficulty tracking information across rows or down columns understand the layout of the data. More information about including summaries is provided in the Table Summaries page.
Although ensuring the structure of tables is critically important for users of assistive technologies, markup is not the only consideration in making tables accessible. How tables are styled also impacts their readability by users with low vision or who are color blind, and also for users with cognitive disabilities such as dyslexia.
Some key considerations to take into account when styling tables include:
- As header cells are often shaded to distinguish them visually, it is important to ensure sufficient contrast with the foreground text.
- Data cells must not be given the same appearance as headers as this can confuse users about their purpose.
- Use consistent alignment of data in cells to help users follow the data (e.g., having all numeric data right-aligned).
- Consider using alternating row colors, or row highlighting, to make it easier for users with perception difficulties to visually track their way across.