Back link

[govuk-design-system]

Use this issue to discuss the back link component in the GOV.UK Design System.

Guidance

https://design-system.service.gov.uk/components/back-link/

Discussion

Discuss this component in the comments below.

[timpaul]

Home Office have made some improvements to the back button which we should consider adopting.

Details here:

• Improving the back button: Home Office design system backlog
• Back link: Home Office design system

[ignaciaorellana]

Sounds like a good idea, maybe we could ask @owenm6 more about this

[owenm6]

I've been working it up for contribution but we don't have a lot of research to go on at the moment. I'll try and chase that up as we have a few teams using it.

[owenm6]

Suggested changes to the back link pattern

When not to use this component

On non-linear flows including a back link could confuse users or stop them completing a task

How to use this component

Adding a page title or ‘back to previous page’ makes it clearer to the user what to expect from the interaction. It also helps increase a users confidence that they will not lose their work.

Research

We have seen some users not understand the context of the current back link design. This has caused them anxiety.

Some users have been concerned that using the back link would lose their work.

Adjustments to design

• change triangle to arrow (chevron)
• use link colour for consistency

Code and examples

[ignaciaorellana]

@igloosi found this example of 'back link' for the 'Visas and Immigration: Apply for British citizenship by naturalisation' service (also has a 'Check your answers' and 'Progress indicator')

[NickColley]

I think there is an opportunity to increase the target size of this component to satisfy WCAG 2.1 Level AAA https://www.w3.org/TR/WCAG21/#target-size

One way to do this would be to have an invisible overlay that increases the touch area, I have made an example of this here: https://back-link-bigger-target-size-example.glitch.me/

[amyhupe]

Dropbox Paper audit

On 9 Jan 2019 the Design System team reviewed a Dropbox Paper document discussing the back link component.

The aim was to reduce the number of places containing guidance and code by:

• migrating relevant, useful content into the Design System itself
• recording important research findings in the community backlog
• removing the original Dropbox Paper page

Below is a record of the outcomes of that review.

If you need to, you can see the original Dropbox Paper content in the internet archive.

Review outcomes

Updates to the Design System

The Design System team will carry out the following updates to ensure that relevant, useful content from the Dropbox Paper file is added to the Design System.

Update the Question pages guidance to say do not disable the browser back button.

Update the back link guidance to say hide the back link if it relies on JavaScript and JavaScript is not available.

[andymantell]

We have had some discussions recently around this component and whether it meets accessibility standards, specifically around the lack of a hover state.

Reading from https://www.w3.org/TR/WCAG20-TECHS/G183.html which says:

This technique describes a way to provide additional cues on hover and focus so that users who may have difficulty perceiving color differences or have low vision can identify them.

But at the moment the back link does not have a hover state at all. Only a focus state. I do wonder whether this means that all links on gov.uk fail this one as well, based on the following quote:

While using this technique is sufficient to meet this success criteria, it is not the preferred technique to differentiate link text. This is because links that use the relative luminance of color alone may not be obvious to people with black/white color blindness.

Which would lead you towards a technique as shown below from the w3 site itself, whereby link underlines get significantly bolder on hover rather than the subtle colour change found in the design system.

In addition, if you take the high level WCAG2 guideline which says "3.2 Predictable: Make Web pages appear and operate in predictable ways.", it would seem to me that the back link should behave in the same manner as other links on the page.

If you also read https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html it says:

Additional Techniques (Advisory) for 2.4.7
Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.
Highlighting a link or control when the mouse hovers over it (future link)

So not a failure as such, but I think there's sufficient suggestion there that would warrant further investigation into the hover states not just for the back link, but also for standard hyperlinks which at the moment only receive a subtle colour change on hover.

[joelanman]

Just to note that https://www.w3.org/TR/WCAG20-TECHS/G183.html is specifically referring to "providing additional visual cues on focus for links or controls where color alone is used to identify them" - which doesn't apply to us as we use underlines to differentiate links.

[joelanman]

I think we can revisit whether back links should be consistent with other links. The original idea was to differentiate them because they do a specific, repeated task of always going back one page. Other links generally go 'forward' and to various different places. The lack of colour also makes them stand out a little less, because although they're high on the page and therefore get seen first, they're not a primary call to action. But this is all open to more discussion and research.

[ChazUK]

Is there any documentation on wether the back link should be an actual link to a page, or if it should utilise the browsers back functionality?

As with @owenm6's discussion it might be better to have a more verbose title for back links that aren't following the browsers default functionality.

[edwardhorsford]

I'd like to propose harmonising the design of back link underlines with breadcrumbs. Since this is about two patterns - I've added detail to my comment on the breadcrumb github issue.

[edwardhorsford]

Is there any documentation on wether the back link should be an actual link to a page, or if it should utilise the browsers back functionality?

As with @owenm6's discussion it might be better to have a more verbose title for back links that aren't following the browsers default functionality.

@ChazUK where possible I'd recommend rendering a real html link, not using the browser functionality.

A few reasons:

• Using browser back functionality requires javascript - so non-js users won't be able to use this to go back
• Whilst browser back is often the where the user should go, it isn't always. It takes the user to the page they were previously on, rather than the logical previous page in the flow. An example of where this might differ is if a user submits data in a form and gets a validation error, they'll be returned to that page with validation message. The browser back would now point to the same page, whereas it should point to the logical previous page in the flow.

I should note that working out where the back link should go is often not a trivial task. Depending on the branching of the journey it can be rather hard. It also can't be hardcoded to the url of the previous page in the flow - if a user has come to the page via check-your-answers, then the back link should point back to check-your-answers, not the previous question.

[terrysimpson99]

The guidance currently says "Always place back links at the top of a page.". It doesn't show an example that includes h1 or anything else. I see the 'Visas and immigration' example posted by ignaciaorellana has it below a breadcrumb trail. It would be helpful if the guidance was explicit in saying things like "above h1" and "below breadcrumbs" if that was the rule we've got similar artefacts. What do people think?

[edwardhorsford]

@terrysimpson99 In general I'd expect services to use either a breadcrumb or a back link. Not both - they're both navigation means for different sorts of uses.

@ignaciaorellana's example actually isn't a breadcrumb - it's a half progress bar, half navigation links (I worked on it 5+ years ago!). In this case I think the putting the back link below nav is correct - it relates more to the current page, whilst the nav links relate to the wider site structure.

[titlescreen]

Whilst doing some user research for HRMC and one particular user with a screen reader (JAW and Windows) commented how they expected the back button to be at the end of the main region.

They were skipping to the h1 and missing the back link at the top.

Not sure if this is common behaviour, has any one else seen this?

[querkmachine]

@titlescreen In the past I've worked with several designers who (arguably, logically) assume that the back link should be in proximity to a next/continue/submit button on a form. I'm not sure how prevalent that particular pattern is, but it might be common enough that your user has come to expect it.

[asier-hmrc]

@querkmachine Some user will want to go back as soon as they land on the page or read the H1.

[querkmachine]

@asier-hmrc Agreed. I do think the current GOV.UK pattern is the most sensible of the options, just theorising why @titlescreen's user was expecting the link to be at the bottom of the page ☺️

[andymantell]

I've seen JAWS users in UR hitting the 1 key straight away just to jump to the h1 element and skip all the cruft at the start of the page. This is definitely a relatively common practice amongst screen reader users, but everyone does it differently. Others will read from the top of the page in a "logical" order, but that's not something you can assume.

Not sure what to do about this, but just echoing @titlescreen's observations.

[titlescreen]

Yeah I get why we have it at the top of the page, however in my experience they have been placed above the h1 so a user could use a keyboard shortcut to jump to the h1 and announce the page from there totally missing the back link.

It was interesting that they expected it at after the primary button as at that point they would likely have a good understanding of the page and may want to go back.

Also given then Alt + Left Arrow Key or the like can be used to go back in the browser's history made me wonder if people have seen users use browser or screen reader specific short cuts making back links less likely to be needed? 🤔🤷‍♀️

[rotellina]

Hello,
I wonder if the Back link page on GDS could be implemented and cover more scenarios so that we can make more informed decision on its use and guide our teams as well, as seems that there are different opinions around it.
Thanks

[that-firefly]

What is the advice for top back links (on top of a page) alongside with save and continue buttons and back buttons at the bottom? Where can I find the guidelines to back to top arrow when the user reaches a certain point of content on a page?

[Gramatter-DIT]

Interesting read. I have to admit I find the placement of the back button at the top of the screen counter-intuitive, especially if the form is long and sometimes on a laptop you have to scroll 3-4 times upwards to select it. On a mobile device the amount of scrolling would be even more excessive.

For me, the natural position would be next to the Continue button. Has any recent user research been conducted for the placement of back links on differing devices?

[joelanman]

@Gramatter-DIT @that-firefly

From research we know the main use case for back link is soon after page load - to check or change a previous answer. After a user has filled in a page, the main action is to continue - there is less need to go back, and there is a danger that if they do they might lose what they entered on the page. It is still possible to go back, either via the browser or our top back link button, but it is not a common need at the end of the page. In general we do not have long forms due to the One Thing Per Page pattern.

[oscarduignan]

Hi all - is there any reason you should display the back link when printing a page? I know people can add the utility class to hide it when printing, but wanted to check if there was any good reason not to do that - since it's not automatically hidden by default when printing

[LewisHarveyNHSD]

Hi all.
We are advised to give a "go back" link at the top to send you to the logical previous step, whilst still making sure the browser back button works as expected.

Making the back link explicitly link to the previous page (rather than just navigating back in the history stack) seems to provide a confusing user journey.
Say you're on a form with 6 question pages, you press "go back" on page 6 to go to page 5, and now you press browser back... You're sent to page 6, because navigating to page 5 explicitly adds an item to the history array.

Having two different ways to go back, but having them provide different results is confusing for the user.

the guidance on the "go back" component states:
`

Although browsers have a back button, some sites break when you use it - so many users avoid it, instead of losing their progress in a service. Also, not all users are aware of the back button.

`

The advice around using "go back" seems to be contradictory, in that in some places it is stated to be a replacement for browser back (for users that aren't aware of browser back) and in other places it's stated that its behavior should differ from browser back

[bas-man-dev]

Hi,
Not sure if I imagined it or not but I thought the guidance for back links on the GDS website specifically mentioned not to place them in a nav bar?
The team I am working with are claiming it's OK because technically they are navigating the website by going back.
We don't current use a navbar for anything else on the user journey. I'm aware from an a11y point of view this isn't great, but wondered if the guidance for back link has changed now?

[CharlotteDowns]

Insights

Ministry of Justice tested the Claim criminal injuries compensation service with users

Participants in the study were unsure whether the Back link component would return them to the previous page or the start of the journey so had less confidence in using it. The Criminal Injuries Compensation Authority (CICA) Digital Team have changed the content of the back link from 'back' to 'Previous page' as a result of the research.

The users they tested with, including those that were blind, also mentioned that they expected the back link to be close to the continue Primary button in their service.

Methods

The Criminal Injuries Compensation Authority (CICA) Digital Team carried out Accessibility testing of their application journey in May 2024 https://claim-criminal-injuries-compensation.service.justice.gov.uk/apply/start-or-resume

This was a qualitative usability study testing the end to end application process with 6 people with access needs. This included 2 blind participants using screen readers (JAWS and NVDA), 2 partially sighted participants using magnification and colour inversion (ZoomText and Microsoft Zoom), and 2 participants with mobility issues using speech to text software (Siri, Dragon).

[ScenarioFactory]

Hi. When implementing the back link in a government service and following the guidance to place the link before the <main> element, the rendered page raises a best practice violation in Axe Core because there is content outside a landmark:

Guidance: https://design-system.service.gov.uk/components/back-link/#how-it-works

Violation: https://dequeuniversity.com/rules/axe/4.10/region

Any thoughts on whether this is a valid issue? The example National Insurance application journey in the guidance raises the same violation. Thanks.