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.

[terrysimpson99]

Interesting. A back link is below the reference and address in 'Rent and lease details. Do you think that's correct? (see below)

[edwardhorsford]

I feel like there's too much white-space between back links and main. Back links have 15px of bottom margin, and main adds 40px of top padding. Together these make quite a bit of white space.

I don't think we need both.

Current (heading size manually adjusted to be more appropriate):

With 15px removed (heading size manually adjusted to be more appropriate):

I somewhat wonder if main should be adding this padding at all - whether back links are inside main or not, should that determine how far they are from the h1?

[timpaul]

The design of the back link component was recently updated in this Pull Request, to be more consistent with the design of the breadcrumb component. The change was reviewed and approved by the Design System working group on 16 March 2020.

Before:

After:

[timpaul]

We had a further recommendation from a member of the working group, during the review mentioned in the previous comment:

It could be helpful if there is guidance as to when the custom 'return to home' text should be used compared to having a secondary button (or link) at the bottom of a form after a green button. I'm assuming that the top is more about navigation and browsing.

[edwardhorsford]

Purely visually, I much prefer the previous back link and the less-tight underline. The arrow is also much lower contrast (though strictly speaking, not required). Back is different than breadcrumbs, and I think a distinct icon is useful.

I made a proposal last year to harmonise the two - but moving the design in the other direction.

Proposal from last year:

Video moving between the two:

My preference would probably be an underline somewhere between the two - not as much space as the back link, but more than the regular underline. I presume it was shifted down in the back link to allow some space below the arrow.

Quick hack with both having same space as back link:

[rachel-robson]

Hello,

Wondering if it might be possible to review the guidance on this component?

I'm seeing a lot of over-engineering happening with back links across services, and there are a couple of scenarios that seem to cause it where I think the guidance could help.

First scenario involves different people's interpretation of this line in the guidance:
"Where possible, ensure it works even when JavaScript is not available."

A lot of teams are interpreting this as they have to implement non JS links as a standard, and this has resulted in fixed URL back links being implemented, which cause issues with rework or flow changes, and aren't necessarily highlighted in a Live service handover, so will cause further issues in the life of a service. There are also services implementing dynamic back links, which have very complex logic and can be very buggy, so again not great in terms of rework and future Live life of the service.

It would be great to see some more detail in that guidance, for example recommending a simple way that a non-JS version can be implemented, without introducing a lot of overhead.

Otherwise, I feel it would be worth dropping this line entirely, and putting more emphasis on the basic implementation of using JS back and hiding if JS is not available.

As a Design Lead, I always recommend that teams start with the basic JS back link and hide it where JS is disabled, and then look to build on that if there are real user insights coming out that the back link needs modified in certain parts of the journey.

The back links within the pages provide very little value to the overall user experience, and they don't seem worth the amount of effort teams are expending on them, so anything to firm up the guidance and give more direction on this would be massively appreciated.

The second scenario cropping up is over-engineering of back links when users are changing answers from the 'Check answers' page.

So sometimes in a journey, changing an answer to a previous question will mean the user has to now answer extra questions that they didn't previously. I have seen teams focusing on the edge case of someone using back links to arrive back at the 'Check answers' page without having completed all of the questions they need to.

Obviously, a very simple solution to this is validating all the answers are complete when the user tries to submit their form from the 'Check answers' page, and if there are answers missing, showing a friendly error that will direct the user back to the start of the flow to complete all of the questions required.

Again, this is what as Design Leads we would advise, as it keeps things simple and linear for the user experience, and it requires minimal dev effort for what is essentially a total edge case.

Unfortunately, some teams are going straight to over complex journey flows, such as adding in loops to complete missed questions and asking the user to learn a whole new set of interactions in order to complete their submission.

I think a bit of extra guidance to cover off this type of scenario would be really helpful, so at least a simple solution can be highlighted as a starting point, and built upon if there is user need for something more complex.

Not sure if this guidance would make more sense in the 'Check answers' pattern, and maybe just reference it in back links too so people can see how it relates?

Happy to discuss, thanks.

[joelanman]

Hi @rachel-robson, thanks for your post, sorry for the delay, we met as a team to discuss

On your two points:

1. The use of JavaScript back links

JavaScript back links are simpler to implement as you say, and don’t need to be updated if your journey changes. However there are some scenarios that can cause issues:

If you interact with an element on the page that changes the browser history (like tabs, or any in-page links) a JavaScript back link will mean users stay on the page. This is probably unexpected as the link is designed to be navigation back to the previous page.

A rare case, but might be applicable to some services: if a user jumps into a service from another site, or from a bookmark, a JavaScript back link will take them back out of the service. Again this would be unexpected.

If these issues don’t apply to your service then the simpler approach of a JavaScript link may work for you, we’ll try and clarify the guidance.

2. Using the back link to go back to Check Answers without having answered all the questions

I’d agree this is very much an edge case as it involves some very unusual user behaviour. So I’d agree that a simple approach is fine - an error when the user gets to Check Answers or submits it.

[frankieroberto]

@joelanman @rachel-robson our service actually shipped a javascript based back button initially, but it has a few issues:

• Link doesn't work when javascript is disabled
• Control-clicking to open in a new tab doesn't work
• We accidentally broke all the back links by adding a Content-Security-Policy which blocked inline scripts 🤦
• If a user submits a question and then gets a validation error message, the back link goes to the same page they're already on (minus the error message), rather than the previous question.

...so we're going through the process of adding the server-side logic to make the back links point to the right places.

[joelanman]

@frankieroberto thanks thats helpful! Just on your first point though, I'd suggest that if using JavaScript, that the link is only added or revealed by JavaScript, so if JavaScript is disabled or fails, there's no link at all. It's an enhancement in any case - a service should ensure the browser back works.

[matthewmascord]

Is one of the issues with Javascript implemented back links that they are often just operating the browser button?

I understand one of the reasons these links were added in the first place was due to user distrust of the 'Back' button due to browser warnings like 'Confirm Form Resubmission' (see below). If the Javascript is just doing window.history.back(); you will still get these when navigating back to pages that were the result of a form submission (e.g. validation errors). If the link is a regular link, you won't.

Is the advice around adding to all question pages problematic? Should they only be advised to be added where there is only a single possible page to go back to, avoiding using them where a page can be arrived at from multiple branches.

[frankieroberto]

@matthewmascord I think it's generally preferable to put the Back link on all question pages. Where’s there’s two (or more!) possible previous pages you could have come from, one way to track this is using a query string param (eg ?from=summary). It can get fairly complicated though!

Also worth noting that sometimes the back link might go to the logical "previous" page, even if the user wasn't actually on that page previously. An example might be a case working system which has a hub and spoke model (say between a case and an event on that case), and a user shares a direct link to a spoke page with a co-worker. In that case, it might make sense to still have a "Back" link (to the case page) even if the user directly landed on the current page. In these instances, it can sometimes be helpful to make the link even more explicit by relabelling it to something like "Back to case".

[matthewmascord]

Thanks @frankieroberto. Great point about being more explicit. I see that was one of the main original suggestions above as Back to [custom page] Doing so would eliminate uncertainty around what 'Back' actually means and effectively rule out implementations that rely solely on Javascript wired up to the browser back button.

[joelanman]

@matthewmascord services can avoid that confusing screen by using the Post Redirect Get pattern - which would fix it for the browser back button too. More discussion here:

https://twitter.com/joelanman/status/1396920130752372742

I'm not sure about adding text to the back link, some pages might have long question text, and I think the user need is 'I want to go back to the last screen I was on to check/change something' so I'm not sure there's a need for the title

[matthewmascord]

Hi @joelanman , thanks, I'd definitely agree that's a best practice. The cases where I've seen this confusing form resubmission screen are when navigating back to a page that had user validation errors - such pages are generally the direct result of the form submission (POST), not a 303 redirect.

[rachel-robson]

Hi @rachel-robson, thanks for your post, sorry for the delay, we met as a team to discuss

On your two points:

1. The use of JavaScript back links

JavaScript back links are simpler to implement as you say, and don’t need to be updated if your journey changes. However there are some scenarios that can cause issues:

If you interact with an element on the page that changes the browser history (like tabs, or any in-page links) a JavaScript back link will mean users stay on the page. This is probably unexpected as the link is designed to be navigation back to the previous page.

A rare case, but might be applicable to some services: if a user jumps into a service from another site, or from a bookmark, a JavaScript back link will take them back out of the service. Again this would be unexpected.

If these issues don’t apply to your service then the simpler approach of a JavaScript link may work for you, we’ll try and clarify the guidance.

2. Using the back link to go back to Check Answers without having answered all the questions

I’d agree this is very much an edge case as it involves some very unusual user behaviour. So I’d agree that a simple approach is fine - an error when the user gets to Check Answers or submits it.

Hi @joelanman,

Thanks for coming back to me.

So off the back of your discussions, will there be any changes coming in the guidance for back links or check answers pages?

I'm thinking, because of the wild differences I have seen in just a few services recently, defining a simple approach to a user trying to submit on a check answers pages that has ended up with blank answers would be really helpful.

Also potentially adding to the back link guidance to show a non-JS implementation of them that is simple, although looking at the follow up comments there maybe isn't one?

It would be good to try and address the confusion we have seen with the current guidance where teams think they have to come up with a really complex way of doing back links as the JS version isn't good enough, but then their complex solution isn't really adding much to the overall user experience. More emphasis on using the basic JS backlink first and then modifying if needed would be really helpful here.

Thanks.

[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).