Tables

Tables vs. list views

Tables should be used for cases where users need to compare pieces of related information. In all other cases, we recommend the use of the list view component (List views). Selecting the appropriate component is important, as they have different accessibility features and behave differently on smaller browser widths.

For example, in Figure 1 you can see a table of “Most populous countries”. If each row were to be presented individually, there would not be sufficient information for the content to have meaning. In Figure 1, the population of the United States seems large, but the user does not have the full story until they see this piece of data in the larger context illustrated in Figure 2.

Most populous countries

Figure 1 - Most populous countries table showing one row 

Most populous countries 

Figure 2 - Most populous countries table showing four rows 

Conversely, Figure 3 illustrates an example where each row of information could be presented individually and retain meaning. In this example, a list view component should be used (Guidelines for List Views).

Attachments

Figure 3 - Attachments table

When to use this component

• Use tables when presenting rows and columns of related information that needs to be compared

When not to use this component

• Avoid using tables to make the layout of a page look a certain way - Use a layout grid instead

• Avoid using tables for data that is long and wordy - Use conventional page headings and paragraphs instead

Best practices

Do

• Keep tables as simple and small as possible 

• Order the columns to reflect the importance of the data to the user 

• Position related columns adjacent to one another 

• Left-align textual data 

• Right-align quantitative numbers like amounts, measures and percentages – Qualitative numbers like dates, postal codes and phone numbers can be left-aligned 

• Consider the experience on smaller devices and, when possible, use a responsive table 

Don’t

• Clip, truncate or obscure cell content 

• Nest tables within other tables - This will make it difficult for screen readers to read the information in the table aloud in a way that makes sense 

• Merge or split cells - Despite being standard markup for tables for many years, some screen readers still do not fully support complex tables with spanned or multiple levels of row and/or column headers 

• Have empty table cells - Blank cells may mislead someone using a screen reader into thinking that there is nothing more in the table 

• Use zebra striping when the table has interactive elements as users may have a difficult time effectively differentiating between disabled, hover, focused and active states 

• Use an inline scroll area within the body of the table – Scroll the content on the page instead 

Tips

• Get users involved in determining what information needs to be displayed and how they will use it 

• Test tables using real content in English and French – Placeholder content may not surface issues with clipping or truncation

Accessibility

The WCAG criteria outlined in this section were chosen because they represent some of the most common failures when designing and implementing these components. For a comprehensive list, please see Web Content Accessibility Guidelines (WCAG) 2.1 (w3.org).

1.3.1: Info and Relationships 

Identify Row and Column Headers

A critical step toward creating an accessible data table is to designate row and/or column headers. The scope attribute identifies whether a table header is a column header or a row header. The scope attribute tells the browser and screen reader that everything within a column that is associated to the header with scope=”col" in that column, and that a cell with scope=”row” is a header for all cells in that row. 

All <th> elements should generally always have a scope attribute. While screen readers may correctly guess whether a header is a column header or a row header based on the table layout, assigning a scope makes this unambiguous. 

H63: Using the scope attribute to associate header cells and data cells in data tables | WAI | W3C 

Associating Cells to Headings 

Relying on visual cues alone is not sufficient to create an accessible table. Tables without structural markup to differentiate and properly link between header and data cells, create accessibility barriers.  

Proper structural markup allows people using screen readers to 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. 

H43: Using id and headers attributes to associate data cells with header cells in data tables | WAI | W3C 

Including Captions 

When a person accesses your website with assistive technologies, they may not be able to perceive tables visually. Data tables very often have brief descriptive text before or after the table that indicates the content of that table. This text should be associated to its respective table using the <caption> element. The <caption> element must be the first thing after the opening <table> tag. 

While it is not necessary for each table to have a caption, a caption is generally very helpful. If present, it should be associated to the table using the <caption> element. 

H39: Using caption elements to associate data table captions with data tables | WAI | W3C 

Understanding Success Criterion 1.3.1: Info and Relationships | WAI | W3C 

1.4.4 Resize Text 

The intent of this success criterion is to ensure that text can be resized without assistive technology up to 200 percent without loss of content or functionality. Users may benefit from scaling all content on the web page, but text is most critical. 

In Microsoft Edge or Google Chrome, you can change the font size by following these steps:

1. Under the three dots in the top toolbar, navigate to Settings 

2. Select Appearance 

3. Under the Fonts section, go to Customize Fonts 

4. Increase the font size by 200% 

F69: Failure of Success Criterion 1.4.4 when resizing visually rendered text up to 200 percent causes the text, image or controls to be clipped, truncated or obscured | WAI | W3C 

Understanding Success Criterion 1.4.4: Resize Text | WAI | W3C 

1.4.10 Reflow 

WCAG success criterion 1.4.10 Reflow (AA) was introduced in WCAG version 2.1 (June 2018). This criterion requires that content be presented without loss of information or functionality, and without requiring scrolling in two dimensions for: 

• Vertical scrolling content at a width equivalent to 320 CSS pixels; 

• Horizontal scrolling content at a height equivalent to 256 CSS pixels. 

There is an exception for parts of the content which require a two-dimensional layout for usage or meaning. In the case of data tables, because the two-dimensional relationship between the headings and data cells are essential to preserve meaning, they are exempt from this success criterion. However, cells within the data table should fit within the size requirement and the content should not be clipped, truncated or obscured.

While scrolling in two dimensions is permitted as an exemption under this criterion, this may still present usability challenges on smaller viewports. Please see the Resources section for examples of responsive tables. 

Content Disappearing

A technique that is often used to make tables more manageable on smaller browser widths is to remove columns. Reflow does not require that content be displayed in the same way on all browser widths, but it must still be available.  

For this reason, it is not a good practice to remove data. Rather, it is recommended to design concise tables and display only the crucial data across all browser widths. This will ensure that users who may need to increase the size of the content will have an equitable experience. 

F102: Failure of Success Criterion 1.4.10 due to content disappearing and not being available when content has reflowed | WAI | W3C  

Understanding Success Criterion 1.4.10: Reflow | WAI | W3C 

Key component features 

Telerik Blazor DataGrid Component - Overview 

Pagination 

The Telerik DataGrid component for Blazor supports pagination. You can dynamically choose different Button counts, change the items per page, configure the input type, and control whether you want to show the page size dropdown to your users. 

Blazor DataGrid Demos - Paging | Telerik UI for Blazor 

Grid Row Selection 

The Telerik DataGrid for Blazor allows you to select an item or a multitude of items. 

Blazor DataGrid Demos - Selection | Telerik UI for Blazor 

Sorting

The Telerik DataGrid for Blazor allows you to sort its data by one or multiple fields in ascending and descending order. 

Blazor DataGrid Demos - Sorting | Telerik UI for Blazor 

Examples

Responsive Design 

In order to be inclusive to all users, we need to consider how our applications behave on smaller viewports. (For more information on viewports, see The viewport is the window to your site – Digital.gov.) While designing and building using responsive design principles will allow you to create an optimized layout for users accessing your application on smaller viewports, this is not the only benefit. This will also ensure you are supporting users with low vision who need to enlarge text by using the browser’s zoom function. 

When possible, it is recommended to use a responsive table. However, if users need to compare information between rows and a traditional table is needed, there are some techniques that can be used to improve the experience on smaller viewports: 

• If the table will scroll horizontally on smaller viewports, ensure that it is clearly indicated to the user that horizontal scrolling is needed so that they do not miss information 

• Ensure that columns and table cells are large enough to be legible – There should not be scrolling within individual table cells 

• Follow the recommendations listed in the Best Practices section 

Resources

Government of Canada resources 

Data tables - Canada.ca design pattern - Canada.ca

5.3 Use tables to organize data - Canada.ca Content Style Guide - Canada.ca 

External resources 

Tables | Ontario Design System 

Table – GOV.UK Design System (design-system.service.gov.uk) 

Exploring Universal And Cognitive-Friendly UX Design Through Pivot Tables And Grids — Smashing Magazine

Table - MudBlazor