search

alphagov / govuk-design-system-backlog

GOV.UK Design System Community Backlog
31 stars 2 forks source link

Cookie banner #12

Open govuk-design-system opened 6 years ago

govuk-design-system commented 6 years ago

What

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

joelanman commented 6 years ago

This may well change with GDPR coming in - looking at GDPR patterns in general might be a better approach

timpaul commented 6 years ago

There's also a need to tell users about updates to privacy policies and similar, for example:

image

ermlikeyeah commented 6 years ago

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

edwardhorsford commented 5 years ago

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 commented 5 years ago

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

MalcolmVonMoJ commented 4 years ago

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

Our reasoning for choosing this was:

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: image

peter-jordan commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

MalcolmVonMoJ commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

On ukgovernmentdigital.slack.com Slack @peterbjordan_gds ??

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

fofr commented 4 years ago

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 commented 4 years ago

Cheers @fofr

paulwaitehomeoffice commented 4 years ago

@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 commented 3 years ago

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

Actions

timpaul commented 3 years ago

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:

image

The research found that:

frankieroberto commented 3 years ago

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

Screenshot 2020-12-10 at 09 26 57

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 commented 3 years ago

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.

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

image 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 commented 3 years ago

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:

They also made the following recommendations.

Guidance

Design

Code

Next steps

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

CharlotteDowns commented 3 years ago

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:

What we decided and what has changed

We decided to:

How we went about building it

We:

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.

Summary of what the GOV.UK Design System team did to make the cookie banner accessible

What we tested for

Issues we found in the first round of manual testing

Fixes we made before a second round of manual testing

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

Findings from the second round of manual testing

Feedback from the GDS accessibility clinic

Outcomes from the accessibility testing and related fixes

calvin-lau-sig7 commented 3 years ago

We’ve updated the guidance in the cookie banner component

We've added more guidance in the cookie banner component to help service teams take the best approach depending on the cookies they use — organised into 3 options.

Teams who added the GOV.UK Design System cookie banner component to their service using the past guidance do not need to make any changes.

Problems we wanted to solve

Since releasing the cookie banner component, service teams told us they still needed to understand:

What we decided and what has changed

We’ve worked to:

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

stevenleggdfe commented 3 years ago

Findings from A:B testing this pattern on Teaching Vacancies

The Teaching Vacancies team A:B tested a range of cookie opt-in banners on our service, including ones based on this design pattern. While user behaviour will differ from service to service, we wanted to share our findings here so that they can help inform future iterations of this design pattern and help to set expectations of cookie opt-in rates for other services.

For context, Teaching Vacancies is a free job-listing service from the Department for Education. It allows hiring staff at schools, multi-academy trusts in England to list jobs, and allows jobseeking teachers and leaders to search and apply for these jobs, save jobs and set up job alerts.

We carried out 2 rounds of testing with a total of 254,756 daily users, and evaluated the cookie opt in rate alongside indicators of user engagement and task success (bounce rate, site search rate, vacancy view rate and jobseeker account creation rate) for 6 different cookie opt-in banner design variants in each round of testing. Findings from the first round of testing informed the designs that we tested in the second round.

The designs included displaying no banner at all, banners with and without an explicit ‘Reject analytics cookies’ button, banners placed at the top and bottom of the screen, banners with different background colours, and a full screen modal design that required users to make a choice about their cookie preferences to be able to see the site. A sample are shown at the bottom of this post.

Our key findings were as follows:

  1. All the cookie opt in banners had a very similar bounce rate, site search rate, vacancy view rate and jobseeker account creation rate. Only slight variations in these rates were detected. They were also very similar when no cookie opt in banner was displayed at all. So, we think that the cookie opt in banner had little to no impact on users’ perception of the relevance of the site to them, or on how likely they were to interact with the service.
  2. It was very rare for users who bounced to choose to opt in to analytics cookies. Even when required to make a choice about their cookie preferences, around half of users bounced before making that choice, and so would not be tracked in a cookie-based analytics tool. (Note - we counted a user as having ‘bounced’ if, on that date, they only viewed the page that they landed on on that date, the cookie opt in banner and/or the cookies preference screen)
  3. The GDS design pattern, which offered an explicit ‘reject analytics cookies’ button alongside an ‘accept analytics cookies’ button, had a higher cookie opt in rate than our previous banner design, which required users to click a link to a separate screen to choose to opt out of analytics cookies. 29% of non-bouncing users opted in when presented with the GDS design pattern, compared to 25% when presented with our previous banner design. These figures rose to 33% and 26% in the second round of testing. The makeup of our user base varies substantially throughout the academic year, so this variation did not surprise us. A possible explanation for this would be that the GDS design pattern takes up more space on a mobile device than our previous design pattern, because of the space taken up by the explicit ‘reject’ button and one line of additional explanatory content.
  4. When users were required to make a choice about their cookie preferences to view the site, either through an ‘accept’ button or by setting a preference on a separate page, 98% of non-bouncing users chose to opt in to analytics cookies. However, despite this, we chose not to implement this opt in banner, because we had limited evidence from the other goal conversion rates evaluated that users were behaving in the same way as if no opt in banner had been displayed at all. We had some - albeit limited - quantitative basis for the belief that this design discouraged users from making a considered choice about their cookie preferences.
  5. The background colour of opt in banners made little or no difference to the cookie opt in rate.
  6. The placement and stickiness of opt in banners made a significant difference to the cookie opt in rate. Making the GDS design pattern ‘sticky’ (so that it remains on the screen even when the user scrolls down) increased the number of non-bouncing users who opted in to analytics cookies from 33% to 53% in the second round of testing. Placing the banner at the bottom of the screen instead of at the top increased this further to 68% of non-bouncing users. Including users who bounced, these figures were 16%, 26% and 33% respectively.
  7. The cookie opt in rate varied significantly by device. For example, the GDS design pattern had an opt in rate of 56% of non-bouncing users on mobile devices, but only 24% on desktop. When the banner was made sticky, these figures went up to 65% and 30%, and when the banner was positioned at the bottom, they went up further to 78% and 47% respectively. We think this is likely because a cookie opt in banner takes up proportionately more screen space on a mobile device than on a desktop device. This is particularly true of our user base, who often use iPhones with smaller screen sizes.
  8. The difference in opt in rates between mobile and desktop introduced significant skew to data gathered in cookie-based analytics tools that could lead service teams to draw invalid conclusions if they are not conscious of this bias. For example, during the second round of testing, 28% of Teaching Vacancies users were on desktop devices, while 72% were on mobile devices. However, if these figures had been calculated using a cookie-based analytics tool (like Google Analytics) then, without accounting for the bias, we would have concluded that only 14% of users were on desktop, and that 86% were on mobile devices. This would have been a 50% underestimate of the proportion of desktop users. To illustrate the impact this skew might have for our service, this could have led us to over-prioritise mobile support in our design and over-prioritise mobile users in user research, which would effectively have given desktop users less of a voice.
  9. Users showed a strong preference for accepting analytics cookies over rejecting them - for this design pattern, in the second round of testing, only 2.6% of non-bouncing users explicitly clicked the 'Reject analytics cookies' button. This number rose to 5.3% if the banner was made sticky, and 6.5% if the banner was moved to the bottom of the screen.

We eventually decided to implement the GDS design pattern, but positioned at the bottom of the screen, because it maximised the opt in rate, minimised the skew, showed no quantitative evidence of reducing user engagement with the service and ensured that users were able to make a clear choice about their cookie preferences.

We hope this is helpful. Feel free to reach out to me on cross-government Slack (steven.legg_dfe) if you’d like to know more.

Screenshots of banner designs tested

Our original banner, and the new GDS design pattern we also tested: teaching-vacancies-cookie-opt-in-variant-top-original teaching-vacancies-cookie-opt-in-variant-top-gds

The same banners, positioned at the bottom of the page - these had higher opt in rates than when positioned at the top of the page: teaching-vacancies-cookie-opt-in-variant-bottom-original teaching-vacancies-cookie-opt-in-variant-bottom-gds

The ‘modal’ banner we also tested: teaching-vacancies-cookie-opt-in-variant-modal

MalcolmVonMoJ commented 3 years ago

Following on from the community meeting on 9th July, @ImranH-GDS asked me to summarise a few questions and decisions we made whilst locking horns with this issue.

Banner when JavaScript disabled

On gov.uk, when JavaScript is disabled, the cookie banner is still shewn. Since analytical cookies require JS, quite right the accept and reject buttons are hidden.

Problem

Decision

Rejecting analytical cookies

What should happen when a user who has previously accepted cookies clicks reject cookies or turns them off via the cookie settings form? We assume that the cookies must be deleted as the banner and settings form refer to cookies specifically rather than analytics in general. The alternative would be to just delete the <script> tag that is also needed for analytics, but this leaves the cookies active.

Problem

Analytics cookies have generic names and are on a high level domain (in our specific case, justice.gov.uk). We delete cookies when reject is clicked. But if the user has been using another service that uses the same cookies (and has accepted them), these are also deleted, so we are inadvertently affecting the analytics of another service.
We recognised that some services might only set these cookies once (e.g. when accept is clicked) and rely on them not being killed off half way through the journey.

Decision

After looking at other government services, and given that the likelihood of this specific situation was so slight, we opted to delete the cookies when the user clicks reject.

More specific cookie information

The information about whether a cookie is active or not could be displayed on the cookie information page. As well as giving more information to the user, this might have benefited our automated tests.

Decision

We didn't take this idea any further given the lack of identified user need (we had enough to do already).

Example of the idea

Name Purpose Expires Active
_ga These help us count how many people visit the service by tracking if you have visited before. 2 years Cookie is currently set
_gid These help us count how many people visit the service by tracking if you have visited before. 24 hours Cookie is not set

Functional cookies

It didn't seem right to use the cookie banner to disable functional cookies.

We use 3 functional cookies.

Decision

martinbean commented 3 years ago

Apologies if I’m weighing in on something I shouldn’t be.

I just wanted to point out that the illustrated implementation in the GOV Design System might fall foul of the Cumulative Layout Shift (CLS) metric if that’s something that’s considered when creating components if the banner is shown dynamically (i.e. with JavaScript after page load).

So if the page loads, and then a few milliseconds layer the cookie banner is shown (and “shunts” the website content down the screen) then that may be visually jarring.

Apologies if this is something that has already been considered, or if I’m crossing a boundary to bring this up here!

vanitabarrett commented 3 years ago

Hi @martinbean ,

Thanks for your message. This is something which came up while we were implementing the cookie banner component and it's also something we had to tackle ourselves recently as we're in the process of adding a cookie banner to the design system site itself.

We decided to go down the route of having a bit of inline JavaScript immediately below the cookie banner HTML to show the banner as soon as possible. When we were testing, we found this improved the CLS score (from 0.178 and 0.541 on desktop and mobile respectively) to pretty much 0. There's a bit more discussion in the pull request itself.

divisathyan commented 2 years ago

Hello, 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

cookie-banner-with-Welsh-content
glenjamin commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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:

Screenshot 2022-03-01 at 14 13 11

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) https://github.com/hmrc/tracking-consent-frontend/issues/168

GaryCullenDev commented 2 years ago

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.

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

image 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 commented 2 years ago

@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 commented 2 years ago

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.

Screenshot 2022-05-31 at 11 57 25

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 commented 2 years ago

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 commented 2 years ago

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:

Desktop and mobile screenshots:

Screenshot 2022-08-23 at 1 15 41 pm Screenshot 2022-08-23 at 1 16 13 pm
querkmachine commented 10 months ago

@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 commented 10 months ago

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 commented 9 months ago

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

Screenshot 2023-11-27 at 21 27 38(1)

connorgurney-user commented 9 months ago

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 commented 9 months ago

@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-user commented 9 months ago

@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 commented 8 months ago

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:

Hope this helps