The Australian Government coat of Arms

Communities of practice

Communities of practice

Cards

layout
cards
content

#1

This section provides guidance on the elements of a card. Cards represent a gateway to more detailed information. Use Cards to provide information, detail about the service or to represent data with which your users can interact.

You can also view the component page on our documentation site for the Cards component.


#2

The image posted above by Gary is an example of some of the work we’ve been doing around a system for creating cards that align to UI-kit (rather than prescribing a specific card layout).

The concept
is that as a designer/dev you can select which pieces you want your card to be made of and it should just work.

Prototype
If you’re interested in poking about with it I’ve got an early draft in CodePen where I was looking into how this might work. https://codepen.io/treb/pen/WdKXyr

In dev
We’ve had a first attempt at implementing the system over on https://gold.service.gov.au/components/ where you can see it in a site and you can check out the

SCSS and React

Some thoughts on Cards and accessibility

  • If the whole card is a link <a> element, we should avoid putting too much content into the element so that screen readers aren’t reading paragraphs of text for one link.

  • If the whole card is ‘clickable’, at least one thing on the card needs to look ‘clickable’ or like a link in order to give it more affordance.

Feedback
We’d love to hear what everyone thinks about this approach or if you have any feedback or ideas?


#3

Block links are a must! They make more of the target clickable, they should be better for accessibility since you don’t have multiple links sometimes with the same text (“link $heading link graphic $heading”), and they make the management heaps easier since you only have one link.

One thing we’ve run into is WYSIWYG editors don’t play nicely with block links. Specifically CKEditor in govCMS mangles them. We ended up with a ‘pseudo block link’ where the elements inside are mostly <span>s with classes that add display: block.

We ended up with a few variations, but the most common one seemed to be title+image+(optional text).


#4

@mgdhs great points!

The way I imagine the cards working is they are broken into sub components with one wrapper component.

On the wrapper component the user can choose if the whole component is a link. If it is then they won’t add a link inside the wrapper. If the wrapper isn’t a link then they can add links inside the component. The wrapper component would also allow the user to add variations to the appearance of the card such as a shadow or a border.

Sub components would have the ability to be full width, potentially have links or all kinds of content inside them. They can also be ordered in any order to suit the needs of the users.

Some examples of subcomponents might be:

  • card heading
  • card image / svg
  • card call to action
  • card content
  • card html
  • card line

#5

Hi All,

I’d like to share some progress of our own Cards on the Digital Guides website. We recently gave them alot of love, so this is a good time to share them.

You can see them in action here:
https://guides.service.gov.au/topics/

Overall, they are one of the most time-consuming components that I work on in Digital Guides. I look forward to a Design System component!

For our usage, the cards represent a content module-- kind of like a book you can open.

We use them in various layouts like:

Under the hood, they are block links as to get the whole area targeted. This technique also allows for keyboard accessibility (tab to them and give it go):

On hover and focus, we applied a subtle but multi-layered animation to make it a bit fun:

  1. Drop shadow pulls out
  2. Top colour border highlights
  3. Text colour fades to black
  4. Carat for Call-to-action shifts a bit

Here are links to the code if you want to have a look:



#6

Thanks for the write up Chris. We based our newest cards on the Digital Guides cards. Its not a one to one adaption, and we haven’t gone back and updated all our old cards yet, but it seemed like a solid implementation and is the direction we’re heading in.


#7

Here is a great example of an accessible card pattern:
https://heydon.github.io/Inclusive-Components/cards-pseudo-content/

I have been thinking about the card component a lot. After a lot of deliberation I think that an extremely simple card component copying something like material designs would be best. The card would literally be a container that gives whatever element it is applied to a shadow and nothing else.

This would allow maximum flexibility and users could use the au-body and headings to do their necessary additional styles inside the card. It would allow them to insert callouts, call to actions and keyword lists without any restrictions.

On the flip-side we could be prescriptive about the elements that go inside cards. I previously mentioned a large list of things that could go into a card component. These would be class names and react components that allow users to style the card in a precise way.

You can see our prescriptive component code here:

My problem with telling people what goes into a card is that we have no idea what will go inside or how it will scale in the future. For example an event listing may use the card appearance for each item that may contain a date. Do we now allow users to add dates into the card component, how does that work?

If we tell people what goes into a card we can better provide accessibility guidance, however this comes at a cost to customisation ( this problem comes up often when building components ). If anyone has any feedback on how prescriptive or flexible cards should be I’m all ears.


#8

Perhaps a simple card component and a few common example implementations? It isn’t possible to outline all possible uses, but there are a handful of common uses that could be really useful as templates to work from.


#9

Thanks @podgkin this gets me thinking-- perhaps a blank or simple card is a useful thing, as the container (block anchor link) styles were the hardest thing to get right.

The second complex piece of CSS is the flexbox that puts the cards in a grid.

@alex.page maybe for generic-use the CSS classes are the most useful thing for front-end devs as the card content is going to be unique for every use case, but the containers can be standardised in a system?


#10

Definitely a discussion worth having.
One of the guys I’m working with checked out the work you’ve done with cards currently and found it a bit too prescriptive.

I thought the material ui card was pretty well structured.


#11

@ChrisLee

Those cards look good, although they could do with some more semantic markup instead of just divs and strong tags.


#12

Thanks @rooby for the feedback. What semantic tags would you suggest for the card?


#13

Cards are rarely used by themselves. Putting them in an unordered list to group them together is usually best practice.

A good example of semantic html and cards ( linked above ):
https://heydon.github.io/Inclusive-Components/cards-pseudo-content/


#14

Heading type information would be better in a H# tag instead of strong and other text is generally better in a p tag than a div. That way the content gets handled better when machines parse it, for example screen readers or other non-browser reader applications.

On a slightly different note, in some cases cards might also be best wrapped in an article or aside tag, so the solution needs to be flexible in relation to which element wraps it.