Table

Column headers

Keep column headers as short as possible, but don't compromise clarity.

• Avoid using single-word labels, such as Name or ID.
• For example, use Employee name or Project ID instead.

Alignment

• Left align textual data such as customer names and addresses.
• Left align numerical identifiers such as invoice numbers, phone numbers, and product codes.
• Right align calculated numerical data such as currencies, measurements, percentages.
• Note: alignment of currency data will depend on the locale.
• Avoid centre alignment of cell data.
• Headers should be aligned with their data.

Empty cells

If your table contains empty cells, take one of the following approaches:

• If the meaning of the empty cell is no data or not applicable, leave the cell empty.
• Alternatively, use a dash (-) to indicate that the cell has not been left empty in error.
• Add aria-hidden to the dash so that it's not read out by screen readers.
• If the meaning of the empty cell is something other than no data or not applicable, use appropriate text to indicate the meaning. For example, if an employee has not worked any hours on a particular day, use 0 (zero).

Requirements

Users should be able to:

• Understand the relationships between elements within the table.
• Compare types of data in different rows and columns.
• Identify table headers from other table content.
• Interact with elements in the table using assistive technology, if applicable.

Interactions

Keyboard interactions

For tables containing interactive elements:

• Tab. Moves focus from the previous interactive element on the page to the first interactive element in the table.
• Pressing ‘tab’ moves focus through all interactive elements within the table.

For a table with expandable sections:

• Tab. Moves focus from the interactive element before the expandable section to the expandable row button.
• Enter or Space. Expands or collapses the row.

For a table with rows that can be reordered:

• Make sure that reordering can also be performed using keyboard commands.

Design considerations

• Tables should be used for comparative data. This helps users understand the relationship between data in cells and in rows or columns.
• Tables should never be used for layout purposes, as this can cause problems for screen reader users.
• If elements do not need to be compared, explore using a ‘tile’ or a ‘list’.
• Make sure that rows of data are easily trackable by eye across the table.
• Consider using key lines to help users read data and understand what it compares to.
• Ensure sufficient contrast between text in cells and the table background.
• Avoid using color alone to convey differences between data in cells. Add additional visual cues.

Development considerations

General, non-interactive table guidance:

• The table element should be used to contain all table data.
• The caption element should provide an overall description of the table's purpose, similar to a heading.
• Table header areas should be wrapped within a thead and the main table content within a tbody.
• Table headers for columns should contained within the thead and given th scope=”col” .
• Table headers for rows should be contained within the tbody and have tr scope=”row” .
• Table rows should be wrapped in tr.
• Table cells should be defined using td.

For tables with expandable rows:

• A button should be provided in the first column of the table.
• When the button is activated and the table row has expanded, a screen reader user will navigate through the rest of the row, before reaching the expanded content.
• Avoid coding clickable table rows as they can cause issues for screen reader users and keyboard-only users.