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 be 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
  ​

[glenjamin]

I'm no longer involved directly with building government services, but hopefully you don't mind me chipping in here.

As more services create joined-up journeys between them, I've been increasingly noticing multiple cookie banners on a single journey - because I'm bouncing through multiple difference service domains - even though from an end-user-perspective I'm still on "gov.uk". I personally find this rather annoying, especially on mobile as the banner is quite large.

I also expect that this would be far less likely to get noticed during the normal per-service user-testing that takes place - unless someone explicitly set out to test for it.

I would if it would be feasible to define a standard set of banner-acceptance cookies across services, to reduce the banner churn for users who interact with multiple services and would like their cookie preferences to be saved once and re-used.

[36degrees]

As more services create joined-up journeys between them, I've been increasingly noticing multiple cookie banners on a single journey - because I'm bouncing through multiple difference service domains - even though from an end-user-perspective I'm still on "gov.uk". I personally find this rather annoying, especially on mobile as the banner is quite large.

I also expect that this would be far less likely to get noticed during the normal per-service user-testing that takes place - unless someone explicitly set out to test for it.

I would if it would be feasible to define a standard set of banner-acceptance cookies across services, to reduce the banner churn for users who interact with multiple services and would like their cookie preferences to be saved once and re-used.

This definitely seems sub-optimal, especially as users are meant to think of GOV.UK as 'a single website' and so are likely to be confused by having to set their cookie preferences over and over.

Unfortunately the architecture of GOV.UK makes this a difficult problem to solve, almost by design – although it presents as a single website, service.gov.uk and www.gov.uk are technically two distinct websites. You cannot set cookies on *.gov.uk in the same way that you cannot set cookies on *.co.uk from one .co.uk domain and read them from another. You also cannot set cookies on *.service.gov.uk (at least not in a modern browser) because it is on the public suffix list.

[36degrees]

We are using the Cookie banner for the Benefit appeal service and it works fine for users who prefer English. For Welsh users, we are displaying the cookie content in Welsh but the cookie banner is still in English.
Could we have support for Welsh Cookie banner

@divisathyan sorry, it looks like we missed your comment. Have you been able to resolve this since you posted? All of the text in the cookie banner component is configurable, so you should be able to customise the text that you are passing it when the rest of the page is in Welsh.

[glenjamin]

You cannot set cookies on *.gov.uk in the same way that you cannot set cookies on *.co.uk from one .co.uk domain and read them from another. You also cannot set cookies on *.service.gov.uk (at least not in a modern browser) because it is on the public suffix list.

Ah, I hadn't appreciated that - I had assumed that because gov.uk is a working domain name that it would be possible to set and share cookies on it.

I could imagine a simple API that allowed requests from *.gov.uk origins with Access-Control-Allow-Credentials could work as a shared opt-in/out.

[CarolineS-QA]

Recently had a DAC audit flag the "Hide this message" as not descriptive enough for WCAG AA (below taken from the report)

DAC Audit

Medium Priority WCAG Level AA
Non-Descriptive Form Elements
Form elements are present that are not descriptive of their function or purpose.

WCAG Reference:
2.4.6 Headings and Labels (Level AA)
Understanding Headings and Labels | How to Meet Headings and Labels
Issue ID: DAC_Non-Descriptive_Form_Elements_01

URL: https://www.staging.tax.service.gov.uk/agent-subscription/business-type

Page title: What type of business are you? - Create an agent services account - GOV.UK
Agent Subscription Journeys
Journey 1: Happy path

What type of business are you?
Screenshot:

Original comment:
The ‘Hide this message’ button related to the Cookies banner is not descriptive enough for
screen reader users to determine its function or purpose when navigating out of context.
Retest comment:
This issue was still present on the page.

Current code ref(s):
body > div.cbanner-govuk-cookie-banner > div > div.cbanner-govuk-button-group > button

Hide this message
Original Solution:
Ensure that all form elements are uniquely descriptive of their purpose. �

Retest Solution:
We would still recommend expanding on the Cookie message by describing to users what
will be hidden.
Example:

Hide cookies message

---

Similar issue (specific to HMRC implementation) hmrc/tracking-consent-frontend#168

[GaryCullenDev]

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

is "accept cookies" or "reject cookies" sufficient if even in reject them essential cookies will still be used?

Surely " Accept all cookies " and "Reject non-essential" would be better?

[edwardhorsford]

@GaryCullenDev the published pattern has a range of different text suggestions depending on what you're accepting or rejecting - I think they might cover your concern?

[vanitabarrett]

We’ve updated the recommended button text for the cookie confirmation message

We’ve updated our guidance in the cookie banner component to make the component more accessible.

When a user chooses to accept or reject cookies, a confirmation message should be displayed. We recommend that the hide button text should be updated to "Hide cookie message" to provide more information for users of assistive tech when read out of context.

Thank you to everyone who raised this issue with us and brought it to our attention.

What you need to do

Teams using the GOV.UK Design System cookie banner component will need to make this change manually in their own service. Replace "Hide this message" with "Hide cookie message".

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

[wilsond-gds]

Hopefully this is the best place to report this rather than the colours discussion?

We’ve had an accessibility audit on the beta version of the digital identity service and the audit picked up that the colour contrast is 4.62:1 between feedback link (#1d70b8 and grey background (#f3f2f1). This passes AA but fails AAA.

Please let me know if you’d like to see the full section of the report for more information.

[henocookie]

Not an area I work on but thought it would be useful to share a variation of the cookie banner that is currently in-use on the Help for Households campaign site, linked to from the GOV.UK homepage. It includes three default button types which goes against the "Avoid using multiple default buttons on a single page" design system guidance for the button component although the current cookie banner in the design system uses two default buttons and a text link.

The buttons on the Help for Households site cookie banner are:

• Accept all cookies
• Reject all cookies
• Set cookie preferences

Desktop and mobile screenshots:

[querkmachine]

@Kate-Nicolson raised an interesting point regarding the placement of the cookie page link in relation to screen readers and content order. Copied here verbatim from #284:

What

The cookie banner layout and tab-order has text then Accept then Reject the Cookies Link.
I think the cookies link should be before the Accept button

Why

I think currently it is a poor design in relation to thinking about the user journey of users with screen readers
In accepting cookies it is supposed to be informed consent - but the user isn't presented with the link to more details about the cookies until after the choice to accept them.
I think the pattern should be updated to either put the link before the 2 buttons, or have the link to the cookies be in the wording above the 2 options.

[CharlotteDowns]

We have removed the 'Experimental' tag from components, patterns, and guidance in the Design System 😌.

The tag was being used on the cookie banner component to raise awareness that more research is needed to validate it. However, we recently published new guidance on how to share findings from users which we hope will make it easier to collect more information about how our Design System is being used across services.

If your team has used this component please let us know 💪🏻.

[simevidas]

@MalcolmVonMoJ

Banner when JavaScript disabled
Decision
We added a button to hide the cookie banner

I do not see any button to hide the banner. This is a problem because the banner is shown at the top of every page. Some people may find this annoying.

[connorgurney-me]

I appreciate that I'm late to the party, but does anybody have any views on the fact that the <h2> in this component is technically before the <h1> of the page?

[joelanman]

@connordoner its not a problem:

You only need to start with the h1 if that makes sense for your content structure and design

https://www.a11yproject.com/posts/how-to-accessible-heading-structure/#what-does-hierarchical-mean%3F

[connorgurney-me]

@connordoner its not a problem:

You only need to start with the h1 if that makes sense for your content structure and design

https://www.a11yproject.com/posts/how-to-accessible-heading-structure/#what-does-hierarchical-mean%3F

Eek! Shows how up-to-date I am. Thanks, @joelanman. 😊

[RichardBradley]

Can I comment that the wording "Option 2: If you set non-essential cookies on the server" and "Option 3: If you set non-essential cookies, but only on the client" on the docs page for this component is quite confusing and not technically accurate.

https://design-system.service.gov.uk/components/cookie-banner/

Specifically the "on the server" vs "on the client" distinction does not make sense. All Cookies are stored on the client machine by definition.

After re-reading it a few times, I think you are trying to distinguish between cookies that are set by headers in the http layer vs cookies that are set by javascript running clientside (so will only appear for users who have javascript enabled).

I would suggest rewording to more like:

• "Option 2: If you set non-essential cookies for users with or without javascript"
• "Option 3: If you set non-essential cookies, but only via clientside javascript"

Hope this helps

[calvin-lau-sig7]

Hi @RichardBradley, thanks for the feedback. The aim of the cookie banner guidance has been to provide useful technical advice whilst being understandable by as wide an audience as possible.

Based on a conversation amongst the tech leads on the team, we're making an update to clarify these 2 scenarios better, particularly that cookies are "set" (rather than stored) by either the server or client-side JavaScript.

[AshGDS]

Hi @simevidas - we have now hidden the cookie banner when JavaScript is disabled on the www.gov.uk domain.

[Kate-Nicolson]

If the cookie banner is hidden when javascript is disabled then make sure that the cookies are never triggered in that scenario - as cookies should only be applied to a session if consent is given or if necessary for the site functions