Short description

Good data tables allow users to scan, analyze, compare, filter, sort, and manipulate information to match their needs.

When and how to use it

Use tables to structure information and provide an overview, allowing the user to spot patterns and possible issues without being overrun with all the details.

Alignment

Table header

• The header row holds the labels for each column. The label should align (left or right) with the data in its column.
• Sorting arrows are placed after the label.
• If checkboxes are used, the “select all” checkbox is placed in the header.

Align text and numbers to the left

• Text. (Name, product, description etc.)
• Non-numeric numbers. (Date, account number, phone number, ID number etc.)

Align text and numbers to the right

• Numeric data. The user should easily be able to compare when scanning down columns. Use the same number of decimal places. (Values in SEK or % etc.)
• Last column. For a nice clean ending of the table. Could be a text or a button.

Navigating via table rows

A table row can serve as a navigation point leading to a subpage or view.

• By default, the entire row displays a hover effect when interactive, and clicking anywhere on it will open the details (either a slide-out or subpage).
  Exceptions: If you need multiple links/clickable areas in one row, then separate and use regular links.
• If the details are on a subpage, a chevron is added at the end of the row to indicate the user will leave the current view.
• For rows with multiple actions, these are grouped into an overflow menu (more) at the far end of the row.

Column order

Left-hand side

• Checkbox
• Expanding chevron (down-arrow)
• If both checkbox and expanding chevron, then the chevron is to the left.

Right-hand side

• Buttons
• Chevron link to another page or modal (right-arrow)
• If both button and chevron link, then the chevron is to the right.

Table footer (summary)

• When used it’s located at the bottom of the table. Use a label (e.g. Total) on the left-hand side.

Responsive tables 

Depending on the size of the tables, the amount of data in it, and what you can do with it. Primarily we see the following three ways to do responsive tables:

1. Prioritised columns

This is the way that makes most sense. Make careful choices as to what columns should be presented or hidden in smaller viewports. Usually it is possible to hide more than you think! When you hide columns, make sure users can still access that information, but in a different view (the detail view).

2. Scrolling table

The table size is fixed and our user can scroll in horizontally to view all columns. This is considered a fallback approach when no other option is doable.

3. Cell table

All, or prioritized columns, are grouped into one cell that may be spread on multiple lines to summarize the columns of the table. Make sure this table is still readable in good accessible way for all users (including screen readers). Make sure this table is still readable in good accessible way for all users (including screen readers).

Cell table

Do's and don'ts

Do

• Try to keep the column names short, preferably to one word. Use tooltip if needed to further explain.
• It is OK to let content inside a table cell wrap into 2 or more rows.
• When form fieds are needed, use the smaller input fields and buttons within in a table or a list.
• Try to simplify and minimise the data added - less is more!

Don't

• Nesting tables can be difficult. Group content as list items instead within a expanded row.
• Having all rows expanded at first does not achieve a better overview. Urge a user to explore interesting content in a specific row or slideout modal.

Column labels

Use short column labels, preferably one word, but no more than three if there is enough space. Use tooltips if you need further explanations.

Upper and lower case

Don’t start each word in headings and labels with upper case. Only use upper case in:

• The first letter of the first word
• The first letter of proper names
• Abbreviations

Use soft hyphens in case of insufficient space

In need of hyphenation, use soft hyphens (­), so that the word is hyphened only if needed.

Empty values

Show the character en dash (–) – instead of empty values.

Aligning numbers

While plain text normally should be left-aligned, values that are numbers should be right-aligned.

Error messages or other messages in tables

In some cases error handling might be needed in tables. Remember to be concise as space is usually extra limited. If the message is short it can be shown in one of the table columns, longer messages are shown in a separate row below the data it concerns. Messages may contain a link to the help page or another page. Messages below should be limited to two rows, including the link.

Example

When a mutual fund has been removed from our range, but the customer still hasn’t changed her or his default fund distribution. When the customer wants to buy funds in accordance with the default fund distribution or change the distribution, an error message is shown in under the old fund.

It is no longer possible to trade in the fund. Change the fund distribution

General considerations

Tables can be more or less comlex. While simpler tables don't require much in terms of accessibility, they can quickly become messy when functionality is added. 
For more complex tables with plenty of interactive elements, it might be good to code the table as a grid to ease keyboard navigation.  

• Be mindful of the tables anatomy. Use semantics for table headings, rows, cells etc. There are both HTML5 elements and ARIA roles for this. 
• If the table is sectioned, the aria role rowgroup can be used. 

To create an interactive widget that has a tabular structure, use the grid pattern instead. If the interaction provides for the selection state of individual cells, if left to right and top to bottom navigation is provided, or if the user interface allows the rearranging of cell order or otherwise changing individual cell order such as through drag and drop, use grid or treegrid instead.

Screen Reader interactions

• Make sure the table container has role table
• If there is an element in the user interface that serves as a label for the table, aria-labelledby is set on the table element with a value that refers to the labelling element. Otherwise, a label is specified for the table element using aria-label.
• If the table has a caption or description, aria-describedby is set on the table element with a value referring to the element containing the description.
• If the table contains sortable columns or rows, aria-sort is set to an appropriate value on the header cell element for the sorted column or row as described in the Grid and Table Properties Practice.
• If there are conditions where some rows or columns are hidden or not present in the DOM, e.g., there are widgets on the page for hiding rows or columns, the following properties are applied as described in the Grid and Table Properties Practice.
  • aria-colcount or aria-rowcount is set to the total number of columns or rows, respectively.
  • aria-colindex or aria-rowindex is set to the position of a cell within a row or column, respectively.
• If the table includes cells that span multiple rows or multiple columns, then aria-rowspan or aria-colspan is applied as described in the Grid and Table Properties Practice.

Resources

• W3.ORG - Table pattern
• MDN web docs - ARIA: table role

Review

Result from the latest accessibility review of the component (Chlorophyll): 2023-06-13

• Contrast: good
• Colour-blindness: good
• Code + aria: ok
• Touch + keyboard: ok
• Dark-mode: n/a
• Focus: ok - uneven
• Reader: ok

• Details: Specification in Figma
• Instruction: How to access Figma