List views

Within the MAACE Design System, we use the term “List View” to refer to a component that displays a list of items and transforms into vertically stacked cards on smaller viewports. List views are a good solution for displaying data on both large and small browser widths without losing its purpose and readability. Please see the Examples section for live demos.

Tables vs. list views 

List views should be used when presenting data where each row of information, if presented individually, would convey enough information for the user to understand that item. Selecting the appropriate component is important, as they have different accessibility features and behave differently on smaller browser widths. 

For a detailed explanation of the differences between Tables and List Views, please see the Tables article.

When to use this component 

• Use list views when presenting related information that does not need to be compared 

When not to use this component 

• Avoid using list views for data that is only meaningful when it is presented in context with other data - Use a table instead 

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

Best practices 

Do 

• Provide clear and concise labels 

• Place labels close to their values and have an ample amount of space between pieces of information 

• Consider how content will wrap on smaller viewports 

Don’t 

• Overload list views with too much content – Cards should include only the important information and link to additional details  

• Clip, truncate or obscure content 

Tips 

• Consider label position on smaller browser widths – Positioning the label on top of the value will reduce the number of eye fixations and allow space for longer values 

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

• Test list views 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.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. 

Understanding Success Criterion 1.4.10: Reflow | WAI | W3C 

Key component features 

Examples 

MITRACK-MonSUIVI 

The MITRACK-MonSUIVI application uses a custom list view component to display their service requests. 

MITRACK - Service requests (tc.gc.ca) 

Open

Figure 1 - MITRACK-MonSUIVI service request list on large browser width 

Open

Figure 2 - MITRACK-MonSUIVI service request list on small browser width

Responsive

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. 

Allowing the content within cards in a list view to reflow from being horizontally stacked on larger screen sizes to being vertically stacked on smaller screen sizes is key to creating a responsive list view. Start by designing the vertically stacked cards for the smallest screen size, and then work with your development team to determine at what breakpoint(s) the content will begin to reflow. Once the design has been implemented, it’s important to test that the content and cards reflow as intended. Ensure that all content is visible, meaning it does not overlap or is situated outside of the screen.

Resources

External resources

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

Cards · Bootstrap (getbootstrap.com)