The Australian Government coat of Arms

Communities of practice

Communities of practice

Breadcrumbs


#1

Please provide any feedback for the Breadcrumbs component.

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


#2

Looking at the schema.org definition for Breadcrumbs, there may be some potential improvements to the default markup suggested for this component:

Suggestion (RDFa, but Microdata would be very similar):

<nav class="au-breadcrumbs" aria-label="breadcrumb">
    <ol class="au-link-list au-link-list--inline" vocab="http://schema.org/" typeof="BreadcrumbList">
      <li property="itemListElement" typeof="ListItem">
        <a property="item" typeof="WebPage" href="https://example.com/">
         <span property="name">Home</span></a>
         <meta property="position" content="1">
      </li>
      <li property="itemListElement" typeof="ListItem">
        <a property="item" typeof="WebPage" href="https://example.com/parent">
         <span property="name">Parent</span></a>
         <meta property="position" content="2">
      </li>
      <li property="itemListElement" typeof="ListItem">
        <span property="name">Current Page</span>
        <meta property="position" content="3">
      </li>
    </ol>
</nav>

If provided examples offer the simplest possible form of markup, it’s a good starting point. It may be worth noting if semantically-enriched versions of the same component are supported.

See also:


#3

In the ‘Rationale’ or ‘Accessibility’ sub-section of this component, I’d suggest linking to either:

https://www.w3.org/TR/2017/NOTE-wai-aria-practices-1.1-20171214/#breadcrumb or
https://www.w3.org/TR/2017/NOTE-wai-aria-practices-1.1-20171214/examples/breadcrumb/index.html

This would allow implementers to note:

The link to the current page has aria-current set to page. If the element representing the current page is not a link, aria-current is optional.

Example markup in the component assumes that the element representing the current page isn’t a link.


#4

One thing we have run into with location based breadcrumbs is how to handle pages with multiple parents. We tested a number of different breadcrumbs with a group of 25 users per breadcrumb, in each case we showed the users a mock up of a page where the only difference was the breadcrumb layout, and then asked the users where they were within the structure of the site.

Home > Parent 1 or Parent 2 > Current item

Users generally reported being within a section called “Parent 1 or Parent 2”, indicating most were not seeing the OR as a logical division, but as part of a single item.

Home > Parent 1 or Parent 2 > Current item

A few users saw these as a logical declaration, some saw it as a typo, most still saw it as a single group.

Home > Parent 1 > Current item
Home > Parent 2 > Current item

More users recognised this as two different paths to the same item, however it was seen as complex and didn’t scale well to more items.

Home > Parent 1 : Parent 2 > Current Item

Some users still saw this as a single content grouping, however a quite a few correctly identified it as two different parent items. This was identified as the best balance of usability and practicality of the options tested.

We considered testing a breadcrumb entirely composed of tags, however this is where testing ceased. None of the options we designed or tested could gracefully scale out to items with 50+ parents which was needed in our use case.

To date we haven’t implemented any of these solutions, but instead opted to rework our content model to produce a distinct page for each instance of shared content. This gave each instance a unique title and breadcrumb. We still have a version with multiple parents, but based on the testing above we are now avoiding displaying this to the user in the breadcrumbs at all. This is effectively a hybrid of location based breadcrumbs and user path based breadcrumbs, which could get confusing if you ever ended up browsing through multiple versions, however in our case most users usually only see one version, or don’t identify the different versions as duplicates.

Just sharing in case others run into the issue.


#5

If all of those pages were being published (and externally crawlable), how would your content model determine which of the pages were canonical?


#6

Take these two pages for instance
https://www.humanservices.gov.au/individuals/services/centrelink/parenting-payment/managing-your-payment/income-reporting

https://www.humanservices.gov.au/individuals/services/centrelink/carer-payment/managing/income-reporting

The rules are the same for both payments, and for another twelve payments, so we manage the rules in one place but display the rules differently depending on where you see them. This way if the user is browsing a payment, they can stay in the context of their payment and not get confused with all the different payments this applies to. They get their own title, breadcrumb, url, child pages and secondary nav.

Unfortunately, as you alluded to, neither of these are actually the canonical version, and while they are an improvement, they are largely ignored by Google. There is still a version of the old single shared page available, and it has the old stub breadcrumb, the old multiparent secondary nav and the non-specific title, and it is the canonical version.

https://www.humanservices.gov.au/individuals/enablers/income-reporting/30331

We could just turn off this version to make the new versions work better in Google, but this would also break all existing incoming links to the old canonical link. We have debated if this is worth it, or if it would even work, but we are currently holding in a compromise situation to maintain existing links. Its disappointing that Google won’t index all the versions, but on the other hand things are no worse than they used to be if you land on a shared page while now being much better if you navigate from somewhere else in the site. So as it stands, for these shared pages if you search for something specific like “income reporting for carers payment”. you’re generally better off clicking the second link in Google rather than the first.

So we still haven’t fully solved the multi-parent breadcrumb issue for people arriving at a page directly from google, we just have the least bad solution we can currently field. As mentioned, the next step would be looking at tags as breadcrumbs.


#7

I’m not sure anyone has solved that yet, so if you find a good solution be sure to share :slight_smile:


#8

Hi podgkin - is there any reason that you couldn’t make your canonical page a disambiguation page the way that Wikipedia does? You could then link to a single page with mostly static content but with the breadcrumbs dynamically generated based on the particular context selected by the site visitor.


#9

Great suggestion Jessica! I’ve run it past the team and we think the idea has legs, we’ve added it to our backlog and will do some design work and testing on how it might play out.

I don’t have a timeframe for implementation, but this is now our preferred approach. Thanks again, this is the design community in action!


#10

Hi all. I was wondering if anyone has tackled ways to handle long breadcrumb strings on smaller screens?

Some examples on au.gov sites i’ve seen are;

  • do nothing
  • hide them entirely
  • hide the current page in the string

Other options we are considering are;

  • only show the direct previous parent page
  • jquery solution to truncate the breadcrumbs based on screen size
  • Change to a “< back” button
  • Change to a “Where am i?” dropdown

This is for the ABS website where we have some long page titles that are about 3-4 levels deep. Our goal for the breadcrumbs is still to help users understand where they are in the site and to work as another navigation option.

Interested to hear any findings you may have already uncovered.


#11

Another thing I’ve seen at mobile sizes is displaying one crumb per line and have it running down the page, but in that case you have to be careful not to use up too much screen real estate.


#12

It depends on a lot of factors. Here are some questions I would ask:

  • How important is it for your user to know where they are on the site?
  • Is the content on the page more important than knowing where the user is in the structure of the site?
  • Is there another way to show the user where they are on the website ( category headings )?

I would always recommend testing with real users as there is no perfect answer, my gut feeling is that the content is always more important then the site structure on a mobile device. However this can be very wrong depending on many different factors.

I would usually avoid changing the markup of the breadcrumbs on mobile devices as that can be confusing or potentially not scale very well for the whole site structure.


#13

For long breadcrumbs we could consider limiting the number of breadcrumbs displayed at once. This does not need to be part of the framework and could be done very easy using React etc. Then you replace your first crumb with a “more” button that is an activator for a menu. The menu can list the parent crumbs if absolutely needed by the user. Means you can fit them on a screen, you get all the historical context but keeps the UI clean. The “more dots” have a really strong affordance.

Are we planning a “Menu” component? - Would be great for this and a handy component in general.

Something like this.


#14

Thanks Phil for the experimentation on how long breadcrumbs could work for the user on a mobile device. This is a very tricky area and I would love to see more experimentation. If you end up implementing something like this I would love to know the results of the usability testing.

Here are some questions I have related to this example and how a user interacts with the breadcrumbs:

  • How does the user know what the three dots are or how to interact with them?
  • Does the user tab to the dots then the menu shows or does it show on click?
  • What happens when they lose focus ( blur ) on the last element in the breadcrumb list?
  • How do we tell users of screen readers there is content hidden from them that appears on focus or click?
  • You are already hiding more than half of the breadcrumbs under the three ... so why not just hide all the breadcrumbs?
  • Why not show all the breadcrumbs if the hierarchy of the site is important on mobile? I understand there is potentially a lot of screen real estate lost, however the user can see and interact with it in one click?

It’s a really tricky problem and work like this is extremely valuable so thank you so much!

In terms of a menu, we have au-link-list which could be easily implemented into a menu. We haven’t had much community feedback requesting this.


#15

Awesome questions man.

Disclaimer - I haven’t implemented this or done any testing, just a thought provoker. Would need to do some user testing to see how people interact with such a design.

These are more my thoughts on your questions than responses backed by evidence or standards:
How does the user know what the three dots are or how to interact with them?
The ellipsis is well known representation for the omission of text. It has started to make it’s way into the mainstream as an icon for “more” driven mainly by Material Design. Open up Facebook or Jira (open on my other screen) and you see a heavy use of the horizontal ellipsis. I would look at giving the ellipsis hover states similar to a button as it is an activator to the menu, not a link in itself.

Does the user tab to the dots then the menu shows or does it show on click?
Tough one. Ease of use would be tab, hover or tap - has an impact on screen readers though. Click might be better and works with the aria-expanded attribute easier.

What happens when they lose focus ( blur ) on the last element in the breadcrumb list?
When the breadcrumb list looses focus I would hide the menu, the same when the menu looses focus.

How do we tell users of screen readers there is content hidden from them that appears on focus or click?
Good one, would need to test. I am not an expert with usability, I would look at using the aria-expanded attribute. This would depend on how we activate also.

You are already hiding more than half of the breadcrumbs under the three ... so why not just hide all the breadcrumbs?
I think it’s a matter of context. Breadcrumbs provide navigation but also context. If a person is interacting with a service the context of parent pages is likely to be less relevant as it moves up the hierarchy towards “home”. Hopefully we are not creating deep structures so if a person need to go back to a parent to select a sibling we should not be sending them up many levels. Hence showing the last couple breadcrumbs should provide context and useful navigation links. Where they need to go up higher in the hierarchy or view the full context the menu option gives them that.
This is more an opinion- take alternate views.

Why not show all the breadcrumbs if the hierarchy of the site is important on mobile? I understand there is potentially a lot of screen real estate lost, however the user can see and interact with it in one click?
Visual fatigue… I don’t see breadcrumbs as primary information. Agree they are useful but when you land on a page I would say the content has greater value. When we are on a mobile device do we want the person viewing it to be presented with a breadcrumb list or the content they need. The person’s primary intent is the content or service on the page, they breadcrumbs are a secondary tool to navigate that - hence I would prioritise the page content they have come to view.

Be good to setup some A/B test where users have to navigate up and down a hierarchy and see how they interact with truncated breadcrumbs

Other thoughts team?