Layout Tables vs Data Tables
Historically, HTML tables have been used to achieve a particular layout, such as aligning page elements in rows or columns in multi-column layouts. In these kinds of tables, known as layout tables, there is typically no logical relationship between rows and columns. Yale strongly recommends avoiding layout tables, and instead using CSS for layout.
If a data table must be used, developers should:
- include a
role="presentation"attribute on the table element
- ensure that the content of the table makes sense when linearized
HTML tables are appropriate for presenting data in two dimensions. In these kinds of tables, there are clear relationships between rows and columns, and typically present row headers, column headers, or both. Screen readers afford users special functionality within tables, such as querying the row and column headers associated with any particular cell.
Use Headers and Scope
Data tables should always include table headers (the
<th> element). For short tables and for tables whose data are self explanatory, column headers are sufficient. For long tables or tables where data may be confusing, it is best to include row and column headers.
<th> elements should always have a scope attribute. Column headers should include
scope="col", and row headers should include
scope="row". Including scope attributes allows assistive technology to better understand the logical relationships presented in the table.
Use Table Captions
Tables can be given an accessible name with the
<caption> element. Screen readers allow users to view a list of tables on the page. If the table has an accessible name, a screen reader will provide that name to the user. If not, the screen reader may only read the number of rows and columns. Thus, a
<caption> provides substantial usability benefits, especially if there are more than one table on the page.
<caption> elements are visible to sighted users as well, unless CSS is written to hide them.
Avoid Complex Tables
Yale recommends avoiding tables with multiple levels of row or column headers and headers that span multiple rows or columns on Yale websites. Such tables may be difficult to implement with the correct markup and scope attributes, and even if implemented correctly, may be difficult for users to understand. In most cases, some other presentation of the data, including presenting multiple tables, may be an equally effective alternative to a single, complex table.
Developers who choose to use a complex table should consult the appropriate specifications carefully.
Avoid Empty Cells for Formatting
Table authors may choose to use empty cells to visually format the table, such as to indicate a division in various sections of the table. While this practice may make sense for sighted users, it may not work for blind users. Yale recommends avoiding blank table cells, especially when those table cells are used for formatting. One alternative to using white space for formatting a single table may include using multiple tables.