| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
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 Guidelines for 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
Do provide clear and concise labels
Do place labels close to their values and have an ample amount of space between pieces of information
Do consider how content will wrap on smaller viewports
Don’t
Do not overload list views with too much content – Cards should include only the important information and link to additional details
Do not 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.
| Info |
|---|
Note: 320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For web content which is designed to scroll horizontally (e.g., with vertical text), 256 CSS pixels is equivalent to a starting viewport height of 1024 CSS pixels at 400% zoom. |
Understanding Success Criterion 1.4.10: Reflow | WAI | W3C
Key Component Features
| Info |
|---|
Pending: Telerik does not currently offer a list view component. This item is in the MOLE team’s backlog for future development. |
Examples
MITRACK-MonSUIVI
The MITRACK-MonSUIVI application uses a list view component to display their service requests.
MITRACK - Service requests (tc.gc.ca)
Resources
External Resources
Summary cards – GOV.UK Design System (design-system.service.gov.uk)