Proper tagging and description of data tables simplifies navigation and understanding for users who cannot see the data or need additional help understanding it.



Example 1 — Table with a single header row
Example 2 — Table with row headers
Example 3 — Table with a caption and summary
Example 4 — Table with footnotes

Footnotes are included after the table, not in the tfoot. Both table and notes can be grouped within a figure.

       <th>Birth Rate<a epub:type="noteref" href="#tblnote01">*</a></th>
   <aside epub:type="footnote">
     <p>* Data not available for all years</p>

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 using the td element.

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 cases, the 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.

Table Structures

Tables can be structured to better represent the purpose of sets of rows using the thead (table header), tbody (table body), and tfoot (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 thead 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 tbody 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 tfoot 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 abbr attribute.

<th … abbr="Total insurance">
   Total insurance coverage
   cost on per annum basis
<th … abbr="Total interest">
   Total interest payments
   for the covered period

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.

Related Links