Cookie banner

[govuk-design-system]

What

Help users manage their personal data by telling them when you store cookies on their device.

[ermlikeyeah]

Also: (how) is this different from the cookies link in the footer?

[edwardhorsford]

I'm going to add this to my service. One question: should it say 'GOV.UK uses...' or 'Service name uses...' - I reckon the latter. It's the service setting the cookies, and the service's cookie policy you'll get to when you visit the link.

[chao-xian]

Just to note that a version of this was added to govuk_publishing_components.

[MalcolmVonMoJ]

In Check if you can get Legal Aid, we were using an older pattern until recently.

We have now changed to this pattern as an interim whilst research is ongoing, so it might not be our final decision.

Our reasoning for choosing this was:

• We wanted something that was visibly different from the main GOV.UK cookie banner, so users would recognise that this is not the one they might've just accepted/rejected.
• We wanted something that was more obvious than the then-current banner, so users would be less inclined to just use the service without ignoring it.
• Counter to that, we also didn't want to be too intrusive.
• We didn't want a simple yes/no option as we have mandatory cookies for Welsh language and so to say no was misleading and to say accept all and accept mandatory is starting to get a tad wordy.

So, we kept the current choices (yes/settings) and only amended the look and feel of the banner for the now. Our brilliant user researcher and exquisite content designer have not put this to bed yet and are continuing to look at all the above points.

However, the moment we made this change (March 6th, 2 weeks ago today), we noticed a significant increase in users accepting cookies. Approximately double. This still only puts us at 40% of pre-GDPR levels in round figures.

Google Analytics details:

[peter-jordan]

@MalcolmVonMoJ Thanks for sharing. Just a comment on the mandatory cookies - I didn't understand the logic of accept mandatory cookies as a thing, but like what you have done.

Hope your UR will explore the user journey between GOV.UK and Legal Aid and how users perceive the two banners.

[MalcolmVonMoJ]

Mandatory cookies: my terminology for "strictly necessary cookies".
From gdpr.eu:

Strictly necessary cookies — These cookies are essential for you to browse the website and use its features, such as accessing secure areas of the site. Cookies that allow web shops to hold your items in your cart while you are shopping online are an example of strictly necessary cookies. These cookies will generally be first-party session cookies. While it is not required to obtain consent for these cookies, what they do and why they are necessary should be explained to the user.

Our service uses some cookies that fall into this category, so if we offered a choice to reject all cookies, this would either be misleading or essentially stop them from using the service. We'd therefore need to rephrase it to something akin to "only accept strictly necessary cookies" or "reject all optional cookies". Various different ways of phrasing it but they are all a bit wordy. Anyway, user research continues...

The journey from GOV.UK to the service is part of the research.

[peter-jordan]

Hi again. Also interested in your reasoning

We wanted something that was visibly different from the main GOV.UK cookie banner, so users would recognise that this is not the one they might've just accepted/rejected.

Again, that would be great to explore in UR as there's been a lot of supposition around the need for a consistent pattern. (But may be there a consistently differentiated pattern??)

[MalcolmVonMoJ]

@peter-jordan, I just realised I didn't answer you - or at least not here. Apologies.

If I recall correctly, testing shewed that users could become exasperated when they had just accepted cookies on the GOV.UK page - perhaps the one with the Start button - but then are asked again when they enter the service. It was thought that a distinct pattern (from the main GOV.UK) would help them understand that the question was different, that we are asking for this service only and not the whole of GOV.UK.

[peter-jordan]

Quick response, as I'm not working this pm. I'd like a next week if poss. Monday?

[MalcolmVonMoJ]

Quick response, as I'm not working this pm. I'd like a next week if poss. Monday?

I am working from Tuesday next week. If you want to talk about our decisions, I should be able to find some time. Ordinarily, it would be wise to include our interaction designer as well, but unfortunately today is his last day for a fortnight. I'll see if I can get his thoughts on this and will post them here.

[peter-jordan]

Hey Malcolm.

Any chance of a chat Tue pm or Wed am? I'm trying to pull together an idea of what different depts have been doing.

[MalcolmVonMoJ]

@peter-jordan, yes, I should think so. How can I contact you? I have a few slots this afternoon, most of tomorrow before midday is free too.

[peter-jordan]

On ukgovernmentdigital.slack.com Slack @peterbjordan_gds ??

I'm free 15:00-17:30 today or 09:30-11:00 Wed

[fofr]

For reference, this is what the “Find postgraduate teacher training” service did:
https://bat-design-history.netlify.app/find-teacher-training/updating-cookie-policy-and-banner/

[peter-jordan]

Cheers @fofr

[paulwaitehomeoffice]

@fofr Really useful and interesting to read that. I've also not seen a design history site like that before, great concept. (Reminds me of something in "The Design of Design" by Fred Brooks of keeping a diary of design decisions during a project, both for the project itself, and for others to learn from.)

[CharlotteDowns]

Cookie Banner Update

The GOV.UK team and the Design System are working together on testing and releasing an experimental iteration of the cookie banner.

Objectives of the Cookie Banner

• To provide a consistent experience across GOV.UK services, particularly across user journeys that ask for different types of cookie on multiple occasions.
• To use styles and components consistently with other elements of the GOV.UK Design System.
• To ensure guidance for implementation is easy to follow and applicable to service teams across government.

Actions

• We'll treat the design for the first banner as an experimental iteration and continue to do AA, A/B testing across GOV.UK.
• Designers from both teams will work together with Content Design to get the guidance written for the Design System.
• The Design System team is going to see if the cookie banner can prioritised within the work of this quarter.
• Have a conversation about getting the cookie banner on GOV.UK.
• We'll continue to think about a more generic banner that we could use across multiple services, further conversation about this in December
  ​

[timpaul]

In July 2020 the GOV.UK programme in GDS conducted user research into the impact of displaying multiple cookie banners on GOV.UK within a single user session. They ran 5 60 minute, remote user research sessions. The participants varied in their levels of interest in online privacy.

These are the banners they tested:

The research found that:

• The cookie notices did not put users off completing the task.
• The majority of users accepted the cookie notices without reading them. 
• Consequently, most users thought they were being shown the same cookie notice during the task, leading to confusion.

• Only one participant read the notices and realised they were being shown for different domains.
• Although users commented they would find seeing several cookie notices during a task to be annoying, it wasn’t considered annoying enough to impact the ease of use of the website.
• The cookie notices had a minor impact on perception of trust of GOV.UK. The overriding perception is that government websites can be trusted to handle details securely. 
• There were no notable differences in the reactions or behaviours to the cookie notices between mobile and desktop/laptop users.


[frankieroberto]

For services where users have to be signed in via an account, I wonder whether it’s worth collecting analytics cookie consent via the sign up flow?

Something like this (although perhaps the wording would change):

The advantages would be that it avoids users having to repeatedly answer the same question on every new device or browser, and that the question would never conflict with other buttons or forms in the same page.

There would also be more space to go into more detail about what kind of analytics are collected, how the data is anonymised, shared, etc, which might make the consent more "informed"?

[RosieClayton]

In December 2020 the Design System team tested two different designs of a Cookie Banner, in 8 usability sessions, with users who use assistive technology. The difference between the two designs was the style of button. Design one had a green button for ‘accept cookies’ and a white button for ‘reject cookies’. Design two had two green buttons for the two options.

We used the Blue Badge journey to test the cookie banner alongside other components.

We tested with participants who had little or no vision and used screen readers and ZoomText. Some participants had dyslexia and used Text-to-Speech and Read and Write Gold.

7 out of 8 participants accepted the cookies straight away. They talked about ‘hiding it’, ‘getting rid of it’ or to 'carry on using the page'. Only one participant ignored the cookie banner and didn’t accept it straight away. When asked they said they only accepted cookies on trusted sites and said gov.uk would be a trusted site. P4 thought the cookie setting page was clear.

The understanding of what cookies were varied: some thought it was related to GDPR, others thought it 'made life easier' and was related to autofill and saving email addresses.

We changed the buttons after participant 4 and saw no real difference in behaviour.

Design One - 3 out of 4 participants accepted the cookies straight away

Design Two - 4 out of 4 participants accepted the cookies straight away.

There were no accessibility issues for any participants and they were able to do what they wanted to do with the Cookie banner.

Layout of Cookies seemed to be in a familiar format for participant five (who saw the two green buttons).

[CharlotteDowns]

GOV.UK Design System working group review: Cookie banner component

Representatives from the GOV.UK Design System working group reviewed this contribution in December 2020.

Based on a majority vote, the group decided that:

• The contribution can be published as it is, although technical guidance and implementation were not included in the proposal.

They also made the following recommendations.

Guidance

• Include guidance for how the banner will work without and with JavaScript.
• Consider making the content on the buttons more descriptive, for example, ‘reject non-essential cookies’.
• Include guidance for websites that use no cookies or essential cookies only.

Design

• Consider using buttons of the same affordance, colour and type.
• Consider where to place the ‘view or set cookie preferences’ link, inline or below the buttons.
• Consider designing an additional banner for users who have cookies turned off.
• Consider combining the cookie banner and cookie page component into one full page height component.

Code

• Clarify what the banner behaviour is with or without javascript.

Next steps

Based on this feedback, the GOV.UK Design System team have agreed to:

• Decide the behaviour of the banner that is shown after selecting or rejecting cookies, whether this is one component or two and how cookies are taken and explained to save this information.
• Include the technical part of the guidance.
• Change the buttons to have equal affordance.
• Ensure that the banner works on smaller viewports.
• Determine whether we need additional link styles to align with buttons.

[CharlotteDowns]

Release of cookie banner

The cookie banner component has been published in the Design System.

The cookie banner component allows users to accept or reject cookies which aren’t essential to making your service work.

Problems to solve

We looked to:

• allow users to make an informed decision about whether to accept or reject cookies
• use a solution that used parts of the GOV.UK Design System
• provide useful guidance for service teams all across government
• build a component that works across a wide range of services and technical implementations - and the different ways they make use of cookies
• improve usability of links that were styled as buttons

What we decided and what has changed

We decided to:

• adopt a new cookie banner designed by the GOV.UK team that allows a user to accept or reject cookies by selecting one of two buttons
• provide a cookie page page pattern that lets users understand in more detail how the service is using cookies, and accept or reject different types of cookie
• accept a recommendation from the GOV.UK Design System working group to make the two buttons identical in colour
• write guidance for the cookie banners for service teams with examples for the following use cases:
  • if you’re using essential cookies and analytics cookies
  • if you’re using more than one type of non-essential cookie
  • if you’re only using essential cookies
• acknowledge that most service teams are likely to use JavaScript to implement cookie consent, but to provide some guidance on server-side approaches as well
• conduct user research on a prototype of the cookie banner with users of assistive technologies.

How we went about building it

We:

• took the cookie banner to the GOV.UK Design System working group as a draft example for approval
• tested for accessibility within the Design System team.
• took the cookie banner to user research in November and December 2020
• took the cookie banner component to test with the GDS Accessibility team

Acknowledgements

Thank you to everyone that contributed to this component, including Gavin Wye at GOV.UK and Frankie Roberto at the Department for Education, for their research, design and development ⭐.

How you can help our ongoing user research

Share your research or feedback by commenting on this issue or propose a change – read more about how to propose changes in GitHub

[csutter]

Really great work on this – we will soon be AB testing a variety of cookie banner options on Teaching Vacancies at DfE and will make sure to feed back our findings as well.

One thing I'm not sure I understand is why there is a version for "only essential cookies" at all – my understanding is that that negates the need for a cookie banner, and is something IMHO every service should strive for anyway because they're one of the worst things to ever happen the internet (but that's a personal opinion). See e.g. Github's move to eliminate non-essential cookies.

Perhaps a wider piece of guidance for services around cookies and avoiding them may be helpful, as well as alternatives to serving the business need of gathering data and improving their service – but that's obviously a bit beyond the remit of the Design System!

[paulwaitehomeoffice]

One thing I'm not sure I understand is why there is a version for "only essential cookies" at all – my understanding is that that negates the need for a cookie banner

Could be. Users might still expect to see something telling them what the deal is with cookies, given that they frequently will on other sites. (I'm not familiar with any research on this, so I'm just speculating.)

[hannalaakso]

Accessibility of the GOV.UK Design System cookie banner

We have a card to consider publishing some of these findings in the Design System guidance.

What the GOV.UK Design System team did to improve the accessibility of the cookie banner

• If JavaScript is used to manage cookie consent, use the hidden attribute to toggle the visibility of sections as this will hide the content even if CSS fails to load. display: none; will act as a fallback for legacy browsers (IE 8-10) that don't support the hidden attribute. (The alternative to toggling the visibility of sections in this way would have been to advise teams to replace the cookie banner message markup in the DOM with JavaScript when the user accepts/rejects cookies or hides the banner. This could be a suitable solution in some contexts. However, we decided against using it in our guidance since the Design System components need to be really flexible: we try to avoid patterns where HTML markup needs to be maintained inside JavaScript and this also simplifies localisation of content where relevant.)
• Use aria-label to help users understand what the component is, and role=region to make it a landmark to make it easier to navigate with assistive technologies; this approach is based on the cookie banner used on GOV.UK (before GOV.UK adopted the Design System cookie banner).
• Advise teams to add tabindex=”-1” and role=”alert” to the replacement message and set focus to it when the user has accepted/rejected cookies; this helps some assistive technologies to announce the message. We also remove the visible focus indicator. - see Research on this component.
• Add a transparent border to the bottom of the cookie banner to visually separate it from other page content in high contrast modes.

What we tested for

• We tested the cookie banner in supported assistive technology and browser combinations. In addition, we tested the component in JAWS 2020+Chrome, JAWS 2021+Chrome and JAWS+IE11.

• We tested for the following behaviour on assistive technologies:

  • The title and content are announced when reading page content
  • aria-label on the cookie banner is announced when navigating by landmarks
  • The cookie banner is announced as the first thing on the page, above the skip link
  • The cookie banner is not announced as a landmark after user hides it

• We also tested for the following behaviour when the user accepts or rejects cookies and the replacement message displays:

  • The message content is announced by assistive technologies
  • The focus moves to the message
  • The cookie banner can still be navigated to using landmarks

  This behaviour was tested separately both when the cookie banner:

  • Is built with JavaScript
  • Doesn’t use JavaScript so the page reloads when the user interacts with it

Issues we found in the first round of testing

• Jaws+Chrome, Jaws+IE11 didn’t announce the replacement message.
• Hiding the cookie banner caused Mac Safari to crash when VoiceOver was enabled.

Fixes we made before a second round of testing

To try and fix the above, we did the following:

• Don’t shift the focus to the replacement message
• Set style=”display:none;” in the markup to hide sections (instead of using the hidden attribute)
• Debugging to understand why Mac Safari kept crashing.

Findings from the second round of testing

• The replacement message was being read out correctly on JAWS 2020 + Chrome, and (as kindly confirmed by our colleagues at NHS) in JAWS 2019 + Chrome.
• We pinpointed the JAWS issue to be with JAWS 2021 (testing done with Assistiv Labs) - so it could be a recent regression as the other versions of JAWS announced the message correctly. However our colleagues from HMRC who kindly tried to reproduce the issue for us in Chrome + Jaws 2021 weren’t able to do so.
• JAWS 2021 + Chrome worked in our testing if the focus was not shifted to the message. However, not setting the focus had an adverse effect on iOS VoiceOver (below)
• iOS VoiceOver did not announce the replacement message consistently if the focus was not shifted to the message. Sometimes it read the replacement message but sometimes it read the 'Hide this message' button instead.
• If focus was shifted to the replacement message, iOS VoiceOver did not manage focus correctly after the replacement banner is hidden (in our testing the focus randomly moved to the breadcrumbs)
• Jaws + IE11 announced the replacement message if we set style=”display:none;” in the markup and set style.display = "block" in the JavaScript to show the replacement message (instead of using the hidden attribute)
• We discovered that there’s a weird bug in webkit/Safari where having a pseudo element on the body crashes the browser when an element is hidden in the DOM. However, the pseudo element is something that only appears in our internal review app, so we think it’s unlikely this will be an issue in a live service.

Feedback from the GDS accessibility clinic

• There was some conversation about the placement of the cookie banner before the skip link. We explained that placing it before the cookie banner ensures that users can’t accidentally skip the cookie banner. The fact that the NHS and BBC websites place their cookie banner before the skip link informed our decision as well. Webaim also recommends that the skip link should be one of the first things on the page, rather than the first. Some questions were asked around whether the cookie banner could become an annoyance if users have to go through it multiple times to get to the page content or the skip link. We’ll continue to keep an eye on this.

Outcomes from the accessibility testing and related fixes

• We decided to use the hidden attribute, instead of display: none;, despite display: none; improving the announcements in Jaws+IE11 (see 'Findings from the second round of testing'). We took this decision because the hidden attribute is the semantically correct solution to hide things using HTML (when not using a stylesheet) and it makes the separation between the behaviour of the content (hidden in certain context) and presentation (inline styles) clearer. hidden also hides the appropriate sections of the banner if CSS fails to load, or if the user is using a text-based web browser. What also informed our decision was that Microsoft will discontinue its support for IE11 in spring 2021 and we did not want to tie our implementation to it. However we should consider telling service teams about the implications of hidden for JAWS+IE11; if a service still has some users accessing it on IE11, they could make a decision to use display: none; instead of hidden in the markup.
• As discussed in 'Findings from the second round of testing', the replacement message wasn’t announced in our Assistiv Labs testing by JAWS 2021+Chrome when the user accepted or rejected cookies. However, our colleagues from HMRC weren’t able to reproduce this issue in JAWS 2021+Chrome. Further investigation is needed to understand whether there is an issue here.
• As discussed in 'Findings from the second round of testing', iOS VoiceOver does not manage the focus correctly after the replacement banner is hidden (in our testing the focus randomly moved to the breadcrumbs. We are going to report this to Apple.