Cookie consent: a PECR compliant and accessible solution from Cabinet Office Digital

[Tony-CabOff]

What and why

Here in the Cabinet Office's CDIO Directorate we help policy teams assure and deliver on their proposals for digital services. We recognised there was an urgent need to create a cookie tracking consent solution for users of services we work with that don’t reside on the GOV.UK platform, though they may be reachable from the platform.

This solution is available for service teams and individuals to use with accompanying implementation guidance. It consists of the following components:

• a cookie consent banner;*
• a HTML cookie settings preference page template - configured to be “off” or “opt-in” by default; and,
• a HTML cookie policy page template.

In combination, these components provide service users with the choice to opt in to non-essential cookie tracking in a fully informed and unambiguous manner, and with equivalence in access to opt in/opt out functionality.

How to access it

All three items have been user tested, confirmed as fully compliant with the Privacy and Electronic Communications Regulations (“cookie law”) by the Cabinet Office Data Protection Officer, make use of GOV.UK Design System components and have been independently audited to meet the legally required standard of accessibility; WCAG 2.2, level AA.

We've created versions for use in Node.js, Wordpress and Salesforce as these are the most common platforms used by our services. Click on the links to locate the respective GitHub repositories.

You can find examples of them in use on live services such as Submit trade union facility time data (Node.js), the Civil Service Commission (Wordpress) and the Honours Nomination service (Salesforce)

If you’re working on a Cabinet Office service and need help implementing this solution, please contact us on this channel. We’re also happy to share insight into the thinking and development process behind what we have created more widely.

*_We're currently updating the repositories for this component in Wordpress and Node.js.

[anevins12]

Nice work, out of interest what was the decision based around when making the link ("set cookie preferences") look like a button when it is not? It also has the role of button.

To clarify, the Civil Service Commission uses a button element for the "Set cookie preferences" action but all it does is redirect to another page. In that instance I think it is a mistake and the anchor tag should be used.

The Cabinet Office correctly uses an anchor, but as I see it also incorrectly uses the role of button - and styles the link to look like a button.

[Tony-CabOff]

Thank you. No decision; It was a consequence of the Design System button component [line 15 and 44] which generates an anchor with the button role (instead of an actual button) when href is passed/set: {{ govukButton ({ text: "Set cookie preferences", classes: "govuk-button--secondary govuk-!-margin-bottom-4", href: cocc_pref_href }) }}

[edwardhorsford]

Nice work, out of interest what was the decision based around when making the link ("set cookie preferences") look like a button when it is not? It also has the role of button.

To clarify, the Civil Service Commission uses a button element for the "Set cookie preferences" action but all it does is redirect to another page. In that instance I think it is a mistake and the anchor tag should be used.

The Cabinet Office correctly uses an anchor, but as I see it also incorrectly uses the role of button - and styles the link to look like a button.

@Tony-CabOff (or his team) has chosen to make both options look like buttons - I presume to give equal weight to them and because they're trying to reflect the choice / actions the user has to take. This feels sensible, and matches what GOV.UK does too.

What's important is that the behaviour of the element matches what it looks like - that way it works for assistive technologies. In this case, it looks like a button, and because of the role (and js shim), it behaves like a button.

The design system supports buttons like this because it's a common need - to make things look like buttons where a literal button html element wouldn't work. These have have been tested extensively over the years and test very well with users.

---

Buttons vs links is a common discussion - I suggest adding a comment to the Button component or this issue I raised about better documenting links styled as buttons.

[MalcolmVonMoJ]

We have opted for a similar design, but opted for a green "primary" button for the accept all.

We have discussed it in the other discussion on cookie banners.

[anevins12]

Thanks for the clarification!

[Tony-CabOff]

We have opted for a similar design, but opted for a green "primary" button for the accept all.

We have discussed it in the other discussion on cookie banners.

Nice work. We thought about the green button and various combinations of this in the banner during build but opted to heed the GOV.UK Design System advice to have only one CTA button on a web page. For us this meant having no green button in the banner as it may dilute the import of this navigational function where it appears lower down on the web page.

[MalcolmVonMoJ]

That is an interesting point. It is taking that advice very strictly. I would consider the cookie banner to be a separate page in regard to that advice. The two green buttons are not rivals, click on Accept all cookies and the green navigation button is still waiting for you, prominent as ever.

[Tony-CabOff]

That is an interesting point. It is taking that advice very strictly. I would consider the cookie banner to be a separate page in regard to that advice. The two green buttons are not rivals, click on Accept all cookies and the green navigation button is still waiting for you, prominent as ever.

Indeed, as indicated, we were thinking about reducing cognitive load for the user on the premise of GOV.UK Design System best practice advice but also we aimed to maintain as much of an equivalence between how easy it is to opt in to cookie tracking and setting preferences/opting out as possible. ICO guidance, reflecting GDPR and PECR, asks that consent be as easy to grant as it is to withdraw. Distinguishing colour on either button, we thought, could tip the balance of perception in this context.

[joelanman]

Agree with @Tony-CabOff. Green buttons should be used as the primary call to action. From a users point of view, there is no primary action in terms of accepting cookies - it should be choice for them to make.

[andyjones81]

Hi @Tony-CabOff Following a DAC audit which picked up several issues with a 3rd party control (the one ICO uses) we were pointed in the direction of this control. (I'm assuming you're the same Tony that DAC spoke to about us?)

I've started to implement this in the new site and while the banner shows, hides, displays the preferences, it's enabling and disabling the cookie in the browser, I can see all that working. However. as soon as the page reloads, it just displays the banner again and the radio in the preferences isn't being set, while the cookie preference remains (either enabled or disabled)

@MalcolmVonMoJ did you implement it directly from the npm package and implement as-is?

[mark-affinity]

Hi @awjdigital are you implementing this to a wordpress site or other?

[andyjones81]

Hi @awjdigital are you implementing this to a wordpress site or other?

@mark-affinity It's a website built using node which utilises our own organisation's frontend which extends the GOV Frontend. I can share a link to the beta site to see what's happening, I just can't share the link publicly at the moment.

Digging into the code I also can't see any code in the node version within the all.js to set the radios to selected based on the stored cookie. I'm struggling to see how this works so would appreciate some help if I've done something wrong.

[mark-affinity]

@mark-affinity It's a website built using node which utilises our own organisation's frontend which extends the GOV Frontend. I can share a link to the beta site to see what's happening, I just can't share the link publicly at the moment.

@awjdigital Did the code supplied include the that should go before ?

[andyjones81]

@mark-affinity No it doesn't and there's no function in the node solution called setupCookieChoices() that I can see.

[cmok-xansium]

@awjdigital I've updated co-cookie-consent README.md and push a minor changes. Please fetch the latest repo and let me know if have problem with the instructions.

[CharlotteDowns]

I'm going to close this issue now that we have published a cookie banner component and cookie page pattern in the Design System. Thank you all for sharing your research and prototypes.

Please feel free to add any ongoing findings to the respective backlog items for the cookie page #13 and the cookie banner #12.