August 13, 2024: Revisiting Best Practices for Cards

The Website Implementation Guidelines Group (WIGG) is working on web components for column and grid displays. As part of that work, they need to figure out the best way to represent groups of Card components. We discussed Cards several years ago: February 11, 2020: Building Best Practices for Cards. This is a good time to revisit that discussion and see where things stand today. To kick off the discussion, here are a couple example listings using card components:

Join us to share your card listings, contribute your thoughts, and see what others are doing with their cards!

For a breakdown of what Card components are and when to use them (or not use them!), see the Nielsen Norman Group's article: Cards: UI-Component Definition

Meeting Notes

  • General discussion about the merits of using multiple modes of categorization/navigation for groups of cards (i.e. articles, lists, & headings)
    • Historically, we've tried to avoid using multiple modes of categorization/navigation to avoid region proliferation and making browsing too noisy
    • Current feedback seems to favor using more approaches to provide multiple modes of engagement. While this does lead to additional noise, there's already a lot of noise in long listings, so providing navigability may be worth it in this context
    • Unfortunately, there's no APG example for this pattern, so there is no official best practice at this time
  • Recommendations:
    • Use list to group cards, each card is an <li> - provides easy enumeration of cards, clear card boundaries, and navigation between cards
    • Make each card an <article> inside the <li> - can navigate via landmarks list
    • Start each card with a heading - can navigate via headings list
    • Preference for single tab stop when possible - cards are meant to be small, digestible nuggets of information providing a short entry point to more detailed content.
  • Eli:
    • Non-decorative images at top of card: put image above or below heading in DOM?
    • Keith: visual and semantic order mismatch can be very helpful in this instance; preferable to alter the visual order (e.g. CSS 'order' property) so image comes after heading in DOM
  • Other notes:
    • If there are lots of cards on a page, then it's probably too much for anyone (sighted or screen reader user) to handle
    • Dick: Better to break up long lists/pages, e.g. faculty pages?
    • Eli: perhaps pagination of long lists of cards would be a good general approach
    • Eli: Endless scrolling not recommended (see Nielsen Norman Group article Infinite Scrolling: When to Use It, When to Avoid It)
  • Hadi: would it be a good idea to recommend using arrow keys to navigate between cards?
    • Hadi likes this approach
    • Michael: would need W3C to come up with clearly defined widget role & interaction pattern
    • Dick: would a message at the top of the card listing describing the interaction pattern help?
      • Hadi: as long as it's not over-announced, e.g. each time you enter a card
      • Michael: so much scripting required for the arrow key interaction pattern, scripting a single announcement of the interaction pattern when entering the widget shouldn't be difficult
  • Dick: would a link at the end of the card cause SR user to miss content above it in card?
    • Hadi: SR users tend to start navigating new page in reading mode (aware of card context), but may also navigate by <tab>, in which case they would be less likely to see rest of context

Tags