| Page Properties | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Lists are an aggregation of many items into a logical group with a common theme.
...
Item | Type | Notes |
List name | Text | Can be used in some circumstances in aria to give context to the list. If presented, aria-labelledby would be appropriate, if a presentational heading was used, aria-label would be appropriate. |
List description | Text | TBC |
… | TBC as to whether a visible heading for the list (e.g. You might also like) forms part of the list or whether it falls within the section heading block. Not all list will necessary need to display a visible heading as it might fall under the page header (H1). | |
|
|
*Notes *Additional elements which are not technicaly expected to be content items (e.g. skip links and item counts) also exist, but haven’t been added to content as it isn’t expected to be content editable per se (outside of a dictionary).
Visual Style
Lists in and of themselves don’t have a specific visual style. But within lists, there are common layout patterns.
...
Discuss grid vs flexbox and how to deliver a centred option (e.g. 3 + 2).
Behaviour
Lists themselves are often guided by the content that exists within them, so don’t specifically have a behaviour though there are some behavioural ‘extensions’ to be mindful of.
Lists are always structural, but can also be semantic. Semantic lists allow for ordered and unordered lists (and potentially definition lists).
Any individual list can be considered critical or optional. A critical list always displays its entire contents and is generally used with the list of the core content of the page (e.g. the main product list on a product listing page. An optional list can display a portion of the list, with the remained revealed through user interaction of list controls.
List controls include carousels, ‘batch loading' and pagination, which are defined separately within this section.
Filtering and sorting are also list controls that fall outside of the MVP.
...
Semantic lists, marked as <li> within an ordered list <ol> or unordered list <ul> will provide a count of the items in the list to screen-readers to aid orientation. Where optional lists hide a portion of the list from display, semantic list markup would only reveal the visible portion and deliver a list count that is misleading. For this reason, optional lists need to deliver an alternative experience. The general best practice recommendation is to create an item count such as “showing X of Y items” and apply a polite live region to that phrase. If/when list controls are applied (e.g. carousel or load more) the user will be told the status of what is available. Key use cases for this include:
Reading out the revised list count when filters are applied.
Reading out the revised list count (like Finish) when more items are loaded with ‘load more’ (e.g. showing 24 or 48 items).
Reading the progression through the list across a carousel (potentially “showing items 1 to 5 of 15” or possible fallback “showing batch/slide X of Y”.
Lists can be named and potentially even described. These fields can be used to populate aria-label, aria-labelledby and aria-describedby functions as relevant.
For long lists, if keyboard users are required to tab through a large amount of items it is often considered best practice to offer those users the ability to skip the list (much like a hidden skip link at the start of the page which becomes visible on focus). This is not needed for all lists, but is a valuable enhancement where there are a lot of tab-stops.
...
Tracking of list performance for some types of lists is critical to understanding performance. An example is the ability to track list impressions in Google Analytics in a True-View style. This technique requires a data-attributes to log the position that the item sits within the list. This is only relevant to “optional” (cross-sell and up-sell) product lists, not all lists.
Future Expansion
Ordered lists can default to numbering from 1 in an ascending order within the MVP, but if not difficult to extend, offering ordered list flexibility to address the type, start and reverse attributes to give more granular control.
For MVP, we can assume that lists will contain the same type of item (e.g. product cards, testimonials, etc). However we have also seen interaction patterns of brands wanting to “insert” teasers and similar related content within product grids to promote alternate content. This would result in a non-semantic list and a list count that could be inaccurate if those <aside> items were included in the list count. Due to potential complexity, this type of pattern sits in future expansion.
...
Programmatic v Customisable: A pure approach to headless CMS removes presentation controls, instead delivering presentation programmatically. Whilst it might be possible to programmatically set decisions (e.g. lists over 20 cannot be presented in carousels), is it better to be cautious and provide guidance/recommendation instead and allow for manual implementation of decisions?
What doesn’t need list semantics?: Lists can often be overdone. Some argue that anything that looks like a list should have list semantics and in most cases that is right, but do all multi-item use cases need a list? (e.g. it is likely there is little value in a CTA Block being a semantic list).
Inspiration from elsewhere
...