Tables – GCWeb design system

Tables are a design pattern for displaying data in rows and columns. They provide a structured way to communicate information.

Tables enable people to scan, understand, analyze, compare and act upon the information within them.

On this page

• Considering user needs
• Purpose of tables
• When to use
• When to consider alternatives
• How to implement
  • Provide captions for tables
  • Include clear and concise table headers
  • Use the simplest table structure
  • Align data in columns
  • Order columns and rows by importance to the user
  • Sort rows by importance to the user
  • Provide filters so users can search and reorder table data
  • Add pagination controls for large tables
  • Code responsive tables based on screen size
  • Consider styling rows with alternating colours or zebra stripes
  • Avoid blank (empty) cells in tables
• Case study on improving and simplifying a table
• Meeting accessibility requirements
• Complementary components and functions

Considering user needs

Tables can be a useful choice for displaying information. However, you must be thoughtful in writing content and designing the layout for tables so that the information is easy to understand, accessible and usable for all users.

Using this pattern with UCD guidance supports:

• Users with small screens who have difficulty seeing all the content in a table at one time
• Assistive technology so users accessing content through screen readers can navigate easily and effectively
• Displaying data that is too detailed or precise to be described in text
• Scanning by users to help them quickly find the information they need

Use a table only if there isn’t a simpler way to present your content, such as a list, or in text. Review your content, this page of guidance and the list of available patterns in the UCD Guide to determine if a table is the best design choice to present the information.

Purpose of tables

Tables organize and present data, such as financial, statistical, comparative or numerical information.

Common user tasks in tables include:

• Scan and find records that fit specific criteria
• View a single record or row of data
• Understand and compare data
• Take actions or make a decision based on data

When to use

• To organize related information (for example, Telephone numbers for personal taxes, benefits and trusts)
• To make complex information easier to understand by presenting it in a clear structure (for example, Claim period dates and deadlines)
• To enable users to look up specific information (for example, CRA Office and drop box locations or Travel advice and advisories)
• To highlight trends or patterns in data, although a graph may be better than a table to highlight patterns in data (for example, see graphs and tables in the Usability Performance Dashboard)
• To organize data that is too detailed or precise to be described properly in text (for example, Tax-Free Savings Account (TFSA) holders by age group)

When to consider alternatives

• When forcing text layout, consider using flexboxes, grids, or column count for lists
• When the information can be presented in a list or summarized simply in the text

How to implement

Provide captions for tables

Captions provide information that can help people find, navigate, and understand tables.

If there is a heading and a caption provided for one table, keep the caption and use the wb-inv class so it can only be seen by screen readers.

Captions for tables

A caption describes the table’s purpose.

Captions help people:

• Find a table
• Understand what the table is about
• Decide if they want to read the table

A table caption should:

• Give a clear idea of what is in the table
• Be unique within the context of the page
• Be short and have no unnecessary words
• Start with the most relevant terms
• Make sense on its own
• Follow best practices similar as Headings and titles

A table caption should not:

• Give an interpretation of the data
• End with punctuation
• Contain abbreviations (unless the audience knows the abbreviation better than its long-form equivalent)
• Include promotional messaging (for example subjective claims)

Most screen readers announce the content of captions. When multiple tables are on a page, screen reader users can list all tables along with their captions. A unique caption makes it easier for screen reader users to identify and jump to the specific table they are interested in.

Include clear and concise table headers

There are 2 types of table headers:

• Column headers
• Row headers

Column and row headers

• Give each column and row a unique header that describes the data in that column or row.
• Keep headers as short as possible
• Add units of measure in a row or column header, instead of repeating them in each data cell.

People using screen readers can have the row and column headers read aloud as they navigate through the table. Screen readers speak one cell at a time and reference the associated header cells, so the reader doesn’t lose context.

Use the simplest table structure

It can be difficult to make complex tables accessible and easy to read for people using screen readers or mobile devices.

To make tables useful to the widest possible audience:

• Keep table data short, clear and concise
• Include only data that is relevant to what you are communicating (to help minimize the table size)
• Turn a complex table into one or more simple tables
• Avoid merged cells (as they can be difficult for some people to understand and they pose accessibility issues)
• Avoid tables nested within other tables, they can be difficult for people to understand and pose accessibility issues
• Only use an image of a table when an HTML version is not viable, but there must be a full text version for people using mobile devices or using assistive technology
• If a table has footnotes, place them at the point of need, usually just after the table
• If there are multiple tables on page with footnotes, each footnote needs a unique label

Align data in columns

By default, most column data is left aligned (in left to right languages like English and French). This helps to make the data easily scannable, readable and comparable.

There is one exception to this for numeric data related to size. These numbers should be right aligned to help users identify number size.

Alignment rules for data

Left align

• Textual data (for example: names, descriptions)
• Numeric data not related to size (for example: dates, time, phone numbers, ID numbers)

Right align

• Numeric data related to size (for example: count, percent, dollars)

Centre align

• Avoid and only use for very short data (for example: yes or no values)

Alignment rules for column headers

Align column headers according to their column data (for example: if column data is aligned to the left, the column header should be aligned to the left).

Order columns and rows by importance to the user

The order of the columns in a table should reflect the importance of the data to the user. Prioritize data with the most crucial information starting from the left column.

Related columns should be adjacent. For example, location details like address, city and country should be together. Placing these apart would create more work for users as they scroll or scan the table to compare columns.

Sort rows by importance to the user

The default sort order of rows should be by the first column of data and in an order which makes most sense for the user and the data context.

Sort order options for rows:

• Alphabetical (for city names)
• Chronological (for dates)
• Numerical (for claim periods)
• Ascending (A to Z, oldest date first, lowest number first)
• Descending (Z to A, most recent date first, highest number first)

You may want to allow users to reorder table data to suit their needs: Provide filters so users can search and reorder table data

Provide filters so users can search and reorder table data

Filters can be useful for users when tables are large, or people are looking for specific data or trends in the data.

Filters enable users to:

• Find the specific data that is relevant for their task
• Select a subset of data according to their needs
• Sort data in an order that is relevant to their need
• View trends in different aspects of the data
• Make large data tables usable on mobile devices

Add pagination controls for large tables

Pagination controls in tables give people the choice of how many table rows are displayed on a page. They help people navigate and view large tables in digestible amounts.

If there are more than 12 rows in a table, consider adding pagination controls.

The default number of rows displayed often varies between 5 and 25 rows. Choose the default number of rows based on what makes sense in the context of the table and how people use the data:

• If there is content on the page after the table, consider a lower default number of rows so that it’s easy for people to see the content that appears after the table
• If the data for each row is concise, consider a higher default number of rows
• If the data for each row is lengthy, consider a lower default number of rows

Code responsive tables based on screen size

Some devices may have screens that are too small to display the full width of the table content.

Responsive tables are able to:

• Adapt to different screen sizes while maintaining the logical order and structure of the data
• Prevent the need for horizontal scrolling or zooming on smaller screens

Coding responsive tables ensures that:

• People can easily read and interact with table data regardless of the device they are using
• People with disabilities who are using assistive devices can navigate and understand the table content effectively

For screens that are too small to display the full width of content, a responsive table can be coded to either:

• Display a horizontal scroll bar

• Split the table into separate smaller tables

Consider styling rows with alternating colours or zebra stripes

Using alternating colours or “zebra striping” rows improves legibility, especially on long, complex tables. The striping helps people distinguish rows from each other.

Styling the even and odd rows in a different way can help people who have reading difficulties or who need to enlarge text.

Zebra stripes act as a visual guide so that people:

• Stay focused on the line they are analyzing
• Are less likely to lose their place or interpret the data wrong

Keep the contrast between the two colours subtle, but comply with the minimum colour contrast rules (1.4.3) from the Web Content Accessibility Guidelines (WCAG) 2.1.

Avoid other uses of colour or texture. If you must use textures and colours in a table, explain what the textures and colours mean (for example, in a table note or legend).

Avoid blank (empty) cells in tables

Do not use empty cells to format a table. Instead consider restructuring the table or using multiple tables. Assistive technologies like a screen reader will notify the person if the cell is blank.

Make your table as clear as possible to all audiences:

• If the value is zero, put “0” rather than leaving the cell blank
• If you don’t know what the value is, put “no data”
• If the cell shouldn’t have a value because the headings aren’t relevant, put “not applicable” or “n/a”

If it is necessary for a cell to have no value, explain why in your table's notes, legend or surrounding content.

Case study on improving and simplifying a table

What we did

To improve and simplify the following tables, we:

• Divided a complex table into several simple tables that are more accessible and can be viewed easily on mobile devices
• Provided the summary table first, followed by tables with increasingly detailed information (this means we applied the inverted pyramid approach)
• Created a clear title for each table
• Used existing subheadings previously embedded in the table cells to create table titles
• Added zeros to provide relevant information in otherwise empty cells
• Removed empty cells, rows and irrelevant information and subheadings

Examples before and after improving and simplifying a complex table

Meeting accessibility requirements

The Accessible Canada Act (ACA) requires that content created for the Canada Revenue Agency meets the goal of realizing a barrier-free Canada by 2040. For our digital products, Accessibility Standards Canada follows the European harmonized standard on Information and Communication Technology (ICT). The CRA uses the Web Content Accessibility Guidelines (WCAG) 2.1 to meet the ACA and must be compliant to WCAG level A and AA.

By following the guidance in the User-Centred Design Guide, your web content should meet the following WCAG success criteria:

• 1.3.1 Info and relationships (Level A)
• 1.3.2 Meaningful sequence (Level A)
• 1.4.4 Resize text (Level AA)
• 1.4.10 Reflow (Level AA)
• 2.4.4 Link purpose (in context) (Level A)
• 2.4.6 Headings and labels (Level AA)

While not required, to further enhance accessibility, more information on setting up and coding accessible tables is available from the W3C Web Accessibility Initiative Tables Tutorial.

Complementary components and functions

Additional add-on features and behaviours are available.

• 

  Lists

• 

  Charts and graphs

• 

  Equal height (Equalize)

• 

  Grids