-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cookie banner #12
Comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Also: (how) is this different from the cookies link in the footer? |
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. |
Just to note that a version of this was added to |
@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. |
Mandatory cookies: my terminology for "strictly necessary cookies".
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. |
Hi again. Also interested in your reasoning
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??) |
@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. |
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. |
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. |
@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. |
On ukgovernmentdigital.slack.com Slack @peterbjordan_gds ?? I'm free 15:00-17:30 today or 09:30-11:00 Wed |
For reference, this is what the “Find postgraduate teacher training” service did: |
Cheers @fofr |
@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.) |
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. |
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, |
@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. |
Ah, I hadn't appreciated that - I had assumed that because I could imagine a simple API that allowed requests from *.gov.uk origins with |
Recently had a DAC audit flag the "Hide this message" as not descriptive enough for WCAG AA (below taken from the report) DAC AuditMedium Priority WCAG Level AA WCAG Reference: 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 What type of business are you? Original comment: Current code ref(s): Hide this message Retest Solution: Hide cookies message Similar issue (specific to HMRC implementation) hmrc/tracking-consent-frontend#168 |
@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? |
We’ve updated the recommended button text for the cookie confirmation messageWe’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 doTeams 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 researchShare your research or feedback by commenting on this issue or propose a change – read more about how to propose changes in GitHub |
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. |
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: |
@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:
|
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 💪🏻. |
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. |
I appreciate that I'm late to the party, but does anybody have any views on the fact that the |
@connordoner its not a problem:
|
Eek! Shows how up-to-date I am. Thanks, @joelanman. 😊 |
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 |
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. |
Hi @simevidas - we have now hidden the cookie banner when JavaScript is disabled on the |
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 |
The `@javascript` tag ensures that Javascript is enabled correctly in the browser used for the test and the GovUK cookie banner has a little bit of Javascript (see alphagov/govuk-design-system-backlog#12 (comment)). This appears to affect subsequent tests, presumably as setting cookies with Javascript turned off has affects if Javascript is subsequently turned on.
What
Help users manage their personal data by telling them when you store cookies on their device.
The text was updated successfully, but these errors were encountered: