govuk-design-system-backlog
govuk-design-system-backlog copied to clipboard
alphagov
Back link
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.
Home Office have made some improvements to the back button which we should consider adopting.
Details here:
Sounds like a good idea, maybe we could ask @owenm6 more about this
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.
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
@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')
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/
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.
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.
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.
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.
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.
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.
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.
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?
@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.
Interesting. A back link is below the reference and address in 'Rent and lease details. Do you think that's correct? (see below)
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?
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:
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.
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:
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.
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.
@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.
@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.
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.
@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".
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.
@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
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.
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.