vanitabarrett
commented
3 years ago Note: this is about the macro options for the component. If a service chooses to use the HTML option, then they are able to change the component how they wish.
For most components, we allow text to be changed to give services flexibility to meet their needs and for translation purposes. However, the cookie banner feels different to other components because of the legal element associated with asking users for consent using the recommended pattern, so it might be worth considering in more detail.
There are three parts of the banner which could be changed by users (see each section below)
1. Text within the banner (excluding consent buttons)
Example: cookie banner heading - “Cookies on [service name]”
Most text within the banner will be changed by services so it makes sense for the cookies their service uses. We can provide examples and recommendations in the guidance.
2. Text within the consent buttons
Example: the ‘Accept cookies’ and ‘Reject cookies’ buttons.
In a perfect scenario, we would probably want to enforce this in some way so we could be sure all users followed our pattern. But we also need to consider:
- services which only set essential and analytics cookies. It may be preferably for them to change the button text to ‘Accept analytics cookies’ and ‘Reject analytics cookies’ to be clearer to users
- services accessible in multiple languages, where teams need to be able to render the banner in different languages otherwise users are unable to give informed consent
3. The number of consent buttons
Our recommended pattern includes two buttons for accepting or rejecting cookies. In a perfect scenario we would probably want to enforce that so services are unable to implement a banner that only allows a user to accept cookies (which is non-compliant). But we also need to consider that the banner needs to work when JavaScript is unavailable. If a service still sets some essential cookies when JavaScript is unavailable, they may wish to continue informing users about this by showing the cookie banner, but it probably wouldn’t make sense to show accept/reject buttons in this scenario.
Options
- Guidance only. We recommend the accept/reject pattern but do nothing technically to stop services doing something different. Does this have implications on the guidance we provide? Do we need to add a disclaimer?
- Guidance and some technical limitations. We could do something like: all text in the banner is changeable, but the accept and reject buttons can only ever be shown/hidden together (i.e: you can’t have one showing without the other). This might make the macro options more complex and, if we’re providing people with the option to add their own ‘action’ buttons/links (e.g: for hiding the banner; for linking to the cookies page), then it’s possible services could use this as a workaround anyway if they really wanted to.
- [not recommended!] Strict technical limitations. A user is unable to change anything about the consent buttons.
What could Option 2 look like?
Could look something like this. However, it makes the Nunjucks API a more complicated as we need to introduce explicit options for the consent buttons, so probably need to weigh up that with how much control we really want over the use, bearing in mind that someone could work around this by using the 'actions' or the HTML.
{{ govukCookieBanner({
banners: [{
title: "Cookies on [service name]",
html: "<p>We use cookies to make this service work</p><p>We'd like to set some additional cookies so we can remember your settings, understand how you use the service and make improvements.</p>",
attributes: {
"data-module": "govuk-cookie-banner-question"
},
consentButtons: {
acceptButton: {
text: "Accept cookies",
attributes: {
"data-accept-cookies": "accept"
}
},
rejectButton: {
text: "Reject cookies",
attributes: {
"data-reject-cookies": "reject"
}
}
}
actions: [
{
text: "View cookies and set preferences",
href: "/cookie-preferences"
}
]
}, {
hideConsentButtons: true,
html: "<p>You've accepted additional cookies. You can <a href='/cookie-preferences'>change your cookie settings</a> at any time.</p>",
attributes: {
"data-module": "govuk-cookie-banner-accept",
"tabindex": "-1"
},
hidden: true
}, {
hideConsentButtons: true,
html: "<p>You've rejected additional cookies. You can <a href='/cookie-preferences'>change your cookie settings</a> at any time.</p>",
attributes: {
"data-module": "govuk-cookie-banner-reject",
"tabindex": "-1"
},
hidden: true
}]
}) }}
What
Partly influenced by https://github.com/alphagov/govuk-frontend/issues/2095 and https://github.com/alphagov/govuk-frontend/issues/2101
A decision on whether text in the cookie banner (e.g: "Accept cookies") is hard-coded or can be changed.
Why
For most components in the design system, all text in the component is passed in, i.e: not hardcoded by us. This is to make things more flexible for service teams and also allows services to pass translations into other languages if needed.
The cookie banner is slightly different as we are recommending a pattern (accept and reject) alongside the component. This may affect how 'locked down' we want the text within the component to be. Ideally the text will be changeable, like other components, but we need to decide what the risks are and if we need additional guidance to make the recommended pattern clear.
Who needs to know about this
Everyone in the team
Done when