govuk-design-system-backlog
govuk-design-system-backlog copied to clipboard
alphagov
Cookie page
Use this issue to discuss the Cookies page guidance in the GOV.UK Design System
This pattern is related to the Cookie banner component
Anything else
I wonder if we need a pattern for this, given that there's guidance in the service manual?
https://www.gov.uk/service-manual/technology/working-with-cookies-and-similar-technologies
Hello @ralph-drewnowski,
In December 2019 the Government Digital Service (GDS) will run a discovery with organisations across government to explore how opt-in consent to cookies on GOV.UK would impact analytics.
After the discovery, GDS will update the Service Manual and GOV.UK Design System with relevant guidance or patterns.
For general guidance on cookies you can read:
Blog: Cookies – what does ‘good’ look like? (https://ico.org.uk/about-the-ico/news-and-events/news-and-blogs/2019/07/blog-cookies-what-does-good-look-like)
We didn't have a pattern so just put something together using the relevant parts from the design system. Whilst a patter might seem like a bit of overkill, I think anything we can do to make pages like this less painful is a good thing.
We could take this as an opportunity to include some same text, or provide some best practice in terms of what content could be included.
On a side note, I think this should be renamed to Cookies as that seems to be the convention, plus it could be a little misleading as we use more than one cookie.
https://www.claim-additional-teaching-payment.service.gov.uk/student-loans/cookies
GOV.UK Design System working group review: Cookie page 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 what state the selections should be when users haven’t yet accepted or rejected cookies.
- Include guidance for websites that use no cookies or essential cookies only.
Design
- Consider using a cookie page example from another service.
Code
- Clarify what the page behaviour is with or without javascript.
- Clarify which cookies are essential and which fit into other categories, for example, functional.
Next steps
Based on this feedback, the GOV.UK Design System team have agreed to:
- Update the cookie page example in the guidance.
- Provide guidance on the states of the radio buttons before a user sets their cookie preferences.
- Determine whether or not to use a success notification banner to provide a user with confirmation that their cookie preferences have been set.
- We've decided to follow GOV.UK in classifying the cookie which remembers cookie preferences as 'essential' rather than 'functional' - because the site appears broken if we're not able to set that cookie.
Release of cookie page
The cookie page pattern has been published in the Design System.
The cookie page pattern tells users about the cookies you’re setting on their device and lets them accept or reject different types of non-essential cookies.
This was developed together with the cookie banner component.
Problems to solve
We looked to:
- help service teams to categorise different types of cookie
- define behaviour if users don’t choose an option in the cookie banner
- understand the experience for users who are not running JavaScript or for services that don’t set cookies
- provide guidance to help users set their cookie preferences at any time
- inform the user that their preferences and been set or changed
What we decided and what has changed
We decided:
- to provide guidance on how to categorise cookies
- to ask services to load the cookies page with radios set to ‘no’ on the user’s first visit. If the user has previously used the service and set their preferences, the page is loaded with those preferences selected
- to ask services to display a different version of the cookies page if users are not running JavaScript
- to ask services to link to the cookies page from the service footer
- if a user updates their cookie preferences using the radios on the cookie page, use a notification banner component to confirm that their new settings have been saved
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
We’ve made minor changes to this page to align with improved guidance on the cookie banner component.
Read about what we’ve changed.
Minor terminology detail: The page talks about cookies 'set on the server'. All cookies are set on the client. A cookie can be set by a server (via the HTTP set-cookie response header) or by the client (via document.cookie using JavaScript), but not 'on the server'.
The guidance to pre-select the "No" option on the consent radios if the user has not yet made a choice seems to contradict the rules for the radios component, which say:
Do not pre-select radio options
Might it be better to leave the radios blank but functionally assume non-consent until the user makes a choice? That seems to achieve the same goal of not setting optional cookies without explicit consent while also not changing existing practice on radios (which must be one of the most commonly used components across gov services).
We have removed the 'Experimental' tag from components, patterns, and guidance in the Design System. 😌
The tag was being used on the Cookies page pattern 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 and format more information about how the Design System is being used across services.
If your team has used this component please let us know. 💪
