Open charlesrt opened 5 years ago
Thanks for putting this together it's pretty exciting to see the progress 👍
We currently have the following documented for what we do to try and help users who need to change their colours:
We aim to support [users who adjust or override the colours of websites they visit][how-users-change-colours-on-websites]. We test this by [changing colours in Firefox][changing-colours-in-firefox], by [enabling 'High Contrast' mode in Windows][enabling-high-contrast-mode-in-windows] and by using the High Contrast plugin for Chrome.
[changing-colours-in-firefox]: https://support.mozilla.org/en-US/kb/change-fonts-and-colors-websites-use
[enabling-high-contrast-mode-in-windows]: https://support.microsoft.com/en-gb/help/13862/windows-use-high-contrast-mode
[how-users-change-colours-on-websites]: https://accessibility.blog.gov.uk/2017/03/27/how-users-change-colours-on-websites/
We have also blogged about this here:
https://accessibility.blog.gov.uk/2018/08/01/supporting-users-who-change-colours-on-gov-uk/
It'd be also worth considering the dark mode for Windows which my assumption is has a much higher use than this, at the same time. There's a related bug for that here: https://github.com/alphagov/govuk-frontend/issues/937
The biggest risk I see from Apple's approach is that if we implement this feature it'll be inconsistently applied across GOV.UK (as most of GOV.UK will not have an up-to-date version of the GOV.UK Design System). Since other dark modes force interfaces to be dark, even if the website has not 'opted-in'
We need to decide if having Apple's dark mode work inconsistently, out weighs that con.
Thanks, Nick. The work done to make GOV.UK accessible to users who change their colours, contrast, etc is great 👍
I’m excited about ‘prefers-color-scheme’ as it lets us control the way this affects the content on GOV.UK, and because the changes would be made through CSS there shouldn’t be any issues like when colours are overridden by plugins, etc (to be clear: I don’t intend that we stop work to make it work for users who override in this way at that might always be a thing).
It’s worth saying that this isn’t an Apple dark mode thing. At the moment this only works in Safari Tech Preview if you are running MacOS Mojave but it’s part of a suite of ‘prefers-‘ media queries that we should expect to come to all browsers soon. I assume that once implemented in a browser available on Windows it will automatically honour a system-level Dark Mode preference set on Windows.
It’s my assumption that this be a wildly implemented on all major platforms and we can be dark-mode-ready, if you like.
I reckon this is an interesting piece of work because we’re talking about setting a preference for an appearance theme rather than overridden and declare precise colours. It’ll involve collaborative work in the community to create a Dark theme and decide what should and shouldn’t change along with adjustments to our colour palette and perhaps even typography as reading experience on dark backgrounds is slightly different.
All of GOV.UK not running the latest version of the Design System is a problem (some satire: a few years ago we spent a lot of effort to replace hundreds of different government websites with one, (feels) more like maintaining hundreds of different government websites on one domain that all look the same but under the hood are individual).
Embedding this as part of the Design System as a considered theme is definitely a must. For older parts of the website they may need manual adjustment. It only took me an hour to hack the prototype kit style sheet to achieve an indicative appearance. It shouldn’t take more than that for a team to do the same for their service. Getting them to do so and release it however may be a policatal challenge.
Lots to think about 🤔
Code used to hack the Prototype Kit for http://govuk-dark-mode.herokuapp.com
@media screen and (prefers-color-scheme: dark) {
body.govuk-template__body {
background-color: govuk-colour("black");
color: govuk-colour("white");
}
header.govuk-header, div.govuk-header__container {
border-bottom: 10px solid #1d70b8;
}
.app-related-items {
border-top: 10px solid #1d70b8;
}
h1, h2, h3, h4, h5, h6, .govuk-heading-xl, .govuk-heading-l, .govuk-heading-m, .govuk-heading-s, .govuk-heading-xs, p, .govuk-list {
color: govuk-colour("white") !important;
}
a:link {
color: #5694CA;
}
a:visited {
color: #DA3984;
}
a:hover {
color: lighten(#5694CA, 10%);
}
a:active {
color: $govuk-link-active-colour;
}
.govuk-back-link, .govuk-breadcrumbs__link {
color: govuk-colour("white") !important;
&:link,
&:visited,
&:hover,
&:active,
&:focus {
color: govuk-colour("white") !important;
}
}
.govuk-caption-xl {
color: govuk-colour("grey-2");
}
div.govuk-panel--confirmation {
background-color: #008F4C;
}
button.govuk-button {
background-color: #008F4C;
}
.js-step-title-text {
color: govuk-colour("white");
}
.app-step-nav-header {
background-color: govuk-colour("black");
}
}
Related Twitter UI dark mode: https://twitter.com/paulmsmith/status/1071454138301595649
The twitter thread commented above shows a screenshot where the Chrome app UI is still Light (presumably as it hasn’t been updated with the functionality) and that this could be confusing.
There is also the suggestion that people might want a Dark UI but Light content. It’s hard to know for sure what people say vs what they’d do. Presently, this isn’t even an option as the preference is declared singularly at system-level. Maybe Apple (and others) will include this sort of choice in the future and ‘prefers-color-scheme’ will take its value from the preference set for content. We need to focus on what’s within our gift.
When considering the implementation of this, we should prioritise the preference set by a user who needs to view content in Dark vs aesthetic preference.
Microsoft are planning on bringing dark mode support to Google Chrome.
https://www.theverge.com/2019/2/7/18215473/google-chrome-dark-mode-windows-macos-support
It would be interesting to consider an implementation of dark mode with CSS custom properties as it'd also allow easy dynamic theming for anyone for example people who use their own user-styles.
Could also make 'inverse' styles easier to implement.
:root {
--background-color: white;
--text-color: black;
}
@media screen and (prefers-color-scheme: dark) {
:root {
--background-color: black;
--text-color: white;
}
}
/* Inverse panel like seen in 'interruption cards' (https://github.com/alphagov/govuk-design-system-backlog/issues/27) */
.inverse {
--background-color: blue;
--text-color: white;
}
@media screen and (prefers-color-scheme: dark) {
.inverse {
--background-color: initial;
--text-color: initial;
}
}
We've seen in research people requesting a similar feature:
the (GOV.UK) background is very bright.. all that white… it’s quite a contrast
sometimes I want to have a black background and white text, especially when you read a lot of text
Wow, stat from (or at least via) Microsoft: High contrast themes are active on 4% of Windows machines. https://lists.w3.org/Archives/Public/www-archive/2019Feb/att-0000/CSSWG_F2F_High_Contrast.pdf … Seems to be some momentum building in the CSS Working Group.
/HT laura_carlson
I’m collecting developer feedback on 🌑Dark Mode☀️ on operating systems and potentially the web (
@media (prefers-color-scheme: dark) {…}
anyone?) for the @GoogleChrome team.Your quick anonymous input on this form would be very appreciated: > https://goo.gl/forms/Qf0wNnc9CVSILq1k2 … 🙏
System-Level Dark Mode coming to iOS13 — meaning a much greater user base with raised expectations using Safari on iPhone.
Chrome 76 release now provides support for dark mode https://developers.google.com/web/updates/2019/07/nic76#dark-mode
Would love to see this feature in the design system, especially now iOS and MacOS have dark mode available natively. I've also noticed an increasing number of websites starting to support this as well.
I think one of the less understood aspects of dark modes for me right now is defaults.
Do users that enable this system level want the website to be dark automatically?
If they don't should there be a way to turn this off and on?
If we need to allow people to turn it off and on, how would that interaction work?
If dark mode only works in some parts of GOV.UK is that a problem?
I think questions like this may need some prototyping and user testing to understand how it could work.
Yeah, 100% needs to be prototyped and user researched.
For me, there should be two levels, system-level and then app level. So macOS than the browser inherits the system preference unless the browser overrides it. Twitter does this well for there iOS app, but this is just Twitter and not everything.
This is still a fairly new feature but with the release of iOS 13 today I can see it being a user want more and more.
The OS-level setting is one thing. The much harder implementation is the site-level (with in-page toggle). How you'd implement that across gov.uk and maintain it as users switch between services, and even departments, in the course of a single journey is key.
We've heard from people with dyslexia that reading black text from a white background (on a page that uses GOV.UK template) is too painful for them. Some compared it to snow-blindness. They found reading the footer - grey text on grey background much easier.
User ticket received on 12/11/19: https://govuk.zendesk.com/agent/tickets/3850591
I am a work coach and have a customer who is dyslexic and struggles to see black on white. The website should be available in alternative/ high contrast format to assist customers like this.
At Companies House we've started looking at dark mode and are about to do some user research around it hopefully. We've adjusted the colours to meet tripple A contrast standards and have adjusted the letter spacing and line height to improve readability in dark mode. This is turned on through the system settings but we'll be looking at a toggle at the application level as well.
Copied from a message I posted to Slack:
We've been doing usability sessions this and last week with users with access needs. These are recruited uses we're calling surrogates - they're office workers, but not direct users of our service. Today's user really really wanted an accessibility widget on the service so she could adjust the service to her liking - specifically wanting to manually control changing to dark mode.
When Alistair was at GDS I know he and I talked about doing something like that on gov.uk - but I've not heard anything since. Anyone know if anything ever happened on it? It's all very well saying people can customise their browsers, but many won't know how to.
Accessibility widget aside, it feels like it would be good to support dark mode where users have expressed a preference for it.
Is there any movement on this? This issue has been raised by a user whilst we were doing research in to accessibility and I think, given how ubiquitous dark mode now is, it should be a standard feature in govuk-frontend
.
The Google Chrome team are currently working on a new browser feature in Desktop and Android Chrome called "Auto Dark Mode".
It is currently only being rolled out as an origin trial, meaning it will only be available on websites who have opted in to test the feature.
On Wednesday 26th Jan 2022 the GOV.UK team received a report that GOV.UK looked "broken" when this feature was enabled and a discussion was had in the day's Frontend Community meeting. The user must have 'forced' Chrome into this mode using the chrome://flags
settings and searching for "darken websites", so it is currently highly unlikely that any user will run into these issues.
But it does raise a number of questions:
It also raises usability issues that are almost impossible to fix when a user moves across services. For example, if a user has "Dark Mode" auto enabled for "www.gov.uk" this setting won't be persistent across services (since cookies can't be shared between www.gov.uk
and *.service.gov.uk
). This also brings up the issue that since its application is algorithmic and decided via the browser, what happens if different services use different versions of GOV.UK Frontend (or even not use it at all)? It could be that the browser chooses different colours per service.
It's also worth mentioning that the feature comes with lots of options (see screenshot below). It is still unclear as to how (or if) this will be presented to a user, and will they be able to choose each of these options individually.
Options we have at the moment:
Here we don't change anything for the moment and wait to see the results from the Origin trial. It could be that it simply isn't a feature that users want or need, and Chrome pulls the plug on the feature all together. So any work will be wasted time and effort.
The Chrome team allows developers to opt out of the application of the Auto Dark Theme using the following meta tag added to a page <head>
:
<meta name="color-scheme" content="only light">
It is also possible to do this via CSS, for everything, or per-element:
:root {
color-scheme: only light;
}
#my-element {
color-scheme: only light;
}
This gives a team the time to decide on the best option to select, and maybe even time to develop our own dark theme (which will override this feature entirely). The blog post even recommends writing your own dark theme:
We strongly recommend implementing your own curated dark theme instead, in order to respect the user's preference and keep those benefits
At the moment, I feel we should do nothing with "Auto Dark Mode" and wait to see if it is accepted by users. This is backed up by the fact that a small Twitter poll I ran show users don't even know it exists at the moment.
If it is that we start getting more reports of pages looking "broken" I'd recommend we consider using the meta
tag or CSS to temporarily disable the browser algorithm and then get involved in providing this user feedback to the Google Chrome team via the link they have provided.
Ultimately, I think time would be better spent on developing our own "dark theme" than chasing bugs in a single browser's "auto implementation".
I did some digging into Chrome's Auto Dark Mode feature after we received a bug report from an end user that certain inputs were not visible with Auto Dark Mode enabled.
Interestingly, the way that it works on the desktop version of Chrome seems to have some significant differences to the Android version—in particular, there is no way for a website to opt out of it. https://github.com/alphagov/govuk-frontend/issues/2582
We're in the process of upgrading an internal service, including switching its UI from a bespoke design to the Design System. The old design supported a dark mode which was very popular with users, so we've been obliged to continue to support it in our new design too.
I think we started with charlesrt's comment above, and you can see our current SCSS. I wouldn't really advise anyone else use this: it only covers the components that we actually use, isn't suitably tested for public use, and uses extra customisation to integrate with our old UI.
I mostly wanted to highlight that:
Thanks for your contribution / feedback @gregtyler, I'm curious about how you are measuring demand from users? Do you have user-testing results for example or a feedback component across pages? Any information on how you have captured this data would be fascinating to know. Thanks!
Both! It was something we heard about in user testing, but we rolled out some changes before we'd added our dark mode changes and so also were told through our feedback component (this makes it sound like we ignored the user testing, but I've oversimplified and we weren't that naughty!)
Hi, we've recently just completed a Firebreak project here at the Department for Business & Trade 'Investigating Dark Mode' and hoped the initial findings we'd discovered can be expanded upon and implemented in some form within the GOV.UK Design System?
In particular, some of the learnings could be used to create a dark theme for GOV.UK Design System akin to: https://m2.material.io/design/color/dark-theme.html
Additionally, as part of the project my colleague, Ieuan developed a simple yet powerful prototype which potentially would be worth demonstrating.
@Gramatter-DIT that prototype sounds interesting but I can't access it, I get this error:
You are not allowed to access this page You do not appear to be on a trusted network.
See the Digital Workspace page gain access to a trusted network for more information.
@joelanman I'll ask my colleague, Ieuan to get back to you as there maybe security implications. He potentially could arrange a meeting with you or upload a video/gif.
Hi @joelanman here's a gif of what the prototype does. Very simple, but what this does is change the website theme based on the theme set on your OS. So, for instance if a user had their OS theme in Dark, the gov website would change based on the preference set. One of the reasons we thought about doing it this way was the ease of implementing. Because we want this to span all gov services, we thought instead of having toggles or buttons displayed, and us needing to put those buttons in, we would allow the operating system to set the theme. This helps the user as well in the sense that they know where to go to change the theme if needed, as different services would have different button location for the toggle/button. Forgot to mention also, this is a simple CSS change using the @media css rule, with no javascript involved.
Via my colleague, Tom Swart in response to the question received via email from @stevenjmesser
I really like the section looking at the times of day people work, did you make any correlations between that and dark mode?
Assuming dark mode would be most beneficial in times at low ambient light (e.g., after dusk), we found that between 1/3 and 1/2 of users use our platforms after sundown (e.g., during winter), and approximately 10-15% of all user sessions are started after dusk. Therefore we hypothesise that the ability to control the contrast to compensate for low light conditions would benefit a significant proportion of our users
There is also the matter of dark mode potentially saving energy for users and being able to feed into gov sustainability requirements.
https://dodonut.com/blog/does-dark-mode-save-battery/ https://dodonut.com/blog/does-dark-mode-save-battery/
Some wider research on dark mode from Nielsen Norman Group: Dark Mode: How Users Think About It and Issues to Avoid.
Thought it was worth checking in after a year to say that we still have a dark mode on our (internal) service and have expanded it to cover a few MOJ and app-specific components as we've expanded the service. The CSS for it remains quite light.
However, it does feel weird to be doing this in isolation. I know it's not the best it could be, but we don't have the capacity/priority to spend time on it. We'd love it to be a feature the Design System picked up, or to become a community-managed resource so that it can be used and contributed to more widely.
In a lot of implementations of a govuk dark mode (and light mode), I see colours being explicitly set for various elements and classes; would it not be better to just set the default color
and background-color
on the body
(with the prefers media query), then focus on the rarer cases of coloured elements and text (panels, links, buttons, etc.)?
I guess I'm asking specifically in the context of trying to honour the user's OS suggested theme - and not for the cases where a proper govuk theme is being created (e.g. offered as a choice as part of a site-specific a11y feature).
I ask because I'm likely going to have to hack this together myself (for UKRI), so I share the sentiment that I'd rather be using something more authoritative from GDS or the Design System!
Hypothesis: rolling out dark mode across the GOV.UK ecosystem could be harder than rolling out the crown.
There’s a higher degree of visual change, which makes inconsistencies more jarring. For example, if you move between GOV.UK guidance in dark mode, a service in light mode, then jump to an account in dark mode, you’re really going to notice the difference. GOV.UK is supposed to feel like one thing, but this will certainly break that. (The crown is comparatively small and easier to miss.)
It could be harder to create consistency across the ecosystem for dark mode, which requires good comms and services to act on that comms. Alternatively there would need to be a central directive in order to ensure the journeys which most commonly traverse departmental boundaries are consistent.
We possibly won’t be able to tackle this in a user-friendly way until we have cross-government data from the Single Data Environment. However, it may be possible for small, closed-boundary services (like internal services, case management systems, intranets, etc.) to make advances.
Hi @stevenjmesser the solution we proposed within the Firebreak project negates this. The beauty of the way in which we've approached this is that the user will have defined the setting within their operating system so the default state for each GOV.UK website would be already chosen by the user, whether it be dark or light. Thus, they'd be accustomed to this environment.
There are no interactions made by button toggling which would potentially cause jarring visual inconsistencies.
All that's needed is a simple line of code added to the CSS of each GOV.UK site to accept this user choice. I realise logistically it may be some work to do this to each and every site, but in this instance, the positives outweigh the negatives, making for a more user-inclusive experience.
Thanks for the reply, @Gramatter-DIT, but I don't think that would work.
Imagine the following scenario:
Despite the user's browser settings asking for dark mode styling from all 3 websites, only www.gov.uk and Service 2 support dark mode, meaning that Service 1 appears in light mode. This presents a broken, inconsistent experience for the user.
What do you think? Have I missed something?
@stevenjmesser the behaviour you've described is basically that of the entire internet right now, because many sites have made the effort to honour dark-mode preferences while others have not. Until the whole of the internet catches up with the vanguard there will be an uncomfortable mix, but that's not a reason to abandon the pursuit of a much requested feature with many benefits.
The approach described by @Gramatter-DIT (which I assume uses the prefers-color-scheme
CSS media feature) should be the goal here, as this will empower the user to make the choice of styling. It would also support themes that follow light conditions and transition between light and dark mode states to better complement the user's environment.
I appreciate the desire to maintain the consistent look and feel of the gov pages, but the focus of this effort should be on other colours and branding that can be consistent between the styles. The current simplicity and reduced colour palette of the gov styling already lends itself to supporting both modes.
@RobinKnipe Thanks for the reply!
the behaviour you've described is basically that of the entire internet right now, because many sites have made the effort to honour dark-mode preferences while others have not.
I see what you're saying but I don't think we should compare the GOV.UK ecosystem of services to the entire web. They're not comparable domains. The goal of GOV.UK is that it feels like 'one thing' to a user, whereas that is not the goal of the entire web.
What we're not saying is that we won't look at making dark mode available, but we do need to think through a release strategy that ensures consistency for users traversing multiple services in one journey.
@stevenjmesser 21 Jul 2023, 09:35 BST you mentioned the a strategic discovery that could involve Dark Mode taking place in October 2023. Has this taken place? The Firebreak project we conducted showed a clear user need, so it'd be great to see to see this being actioned.
Dark Mode hasn't been prioritised by the community as a big need, so it's not part of our plans to work on soon, but we're doing a strategic discovery in October that may reconfigure priorities based on emergent needs.
@Gramatter-DIT We didn’t have the capacity for it in October, unfortunately, the WCAG 2.2 updates took a priority. However, we are reaching out to teams now, and we’re thinking about dark mode anyway.
It’s great that your firebreak project showed that it would be useful. We do have to balance a lot of competing needs across government though, which means we can’t always prioritise your proposal first. For example, more teams have requested we work on navigation sooner.
Are you interested in exploring other ways of you meeting this need for your users?
I’m no longer working on the GOV.UK Design System, but I came across this ‘cheat sheet’ for sustainable web design (Figma file, opens in new window) that might be useful. Some of the points could apply to other elements in the design system too.
A user raised a ticket with GOV.UK that was forwarded to the design system re: the negative impact of very bright screens on neurodiverse users, specifically but not limited to dyslexia. To paraphrase:
@owenatgov I can relate, I suffer from the exact same problem (although perhaps milder). Fortunately brightness is much more easily resolved, and (time-based) blue-light filtering. I understand the desire to keep all of gov.uk singularly themed, but the current (intentionally) stark contrast of the standard design will be a problem for some users.
I suppose there's a question as to when problems like that become ours to solve.
There are users who, conversely, find plain black on plain white to be easier to read than more muted colours or inverse/dark modes. We probably cannot accommodate every combination of colour preferences, so at what point does it become unreasonable to expect users who need particular colours to already have an extension or user styles to supply them?
If we do want to explore changing our default colour combos, we'd probably need to choose our battles.
Something else to add to the mix - https://pubmed.ncbi.nlm.nih.gov/19562598/ It's an old study (2009), so possibly the technical advances in screen resolutions, and a general increase in device luminance since then negates these findings, but it's worth a read if we're looking into a UCD approach to dark mode.
We've been contacted by someone working on the Universal Credit system. They have shared feedback from internal users (via a form on the UC system pages). See the feedback quotes below:
“Dark mode. Please allow us to use dark mode. The pure white screen is maddening.”
“Can we please get a dark mode option? This bright screen triggers migraines. It needs to be more accessible.”
“Please have a DARK MODE option on the screen. Most apps have this option, and it affects the eyes for those with sensitive eyes, especially considering the whole build is stark white. The DARK MODE on Teams is a very good example of the difference between the two. It may not seem like a big deal, but it really does make a massive difference. Thanks”
“Can we get a Dark Mode please?”
“It is 2024 - we need a dark mode be made available for those who are blinded and eyes get very tired through the working day looking at the bright white screen. I can turn my email and Microsoft Teams into dark mode. It's not on we don't have the option for the build we use every working day of our lives.”
“Could we please have a dark mode option for the build - this would help with accessibility”
“Option to have Dark Mode”
“Any chance of creating dark mode for the build as I'm getting eye strain / tension headaches with the white background?”
Please could a dark mode be implemented into the build for those of those that struggle with the bright, white backgrounds?? This would be a benefit to many with health issues regarding this kind of thing.
“Could an option of Dark mode be considered for accessibility reasons? Black text on a white background causes several issues for those with sensory impairments”
What
GOV.UK needs a Dark Mode theme.
Why
I have written about why Dark Mode should be an inclusive design consideration. 2018: The Dark (Mode) Web Rises 2017: Apple Need a Dark Mode 2016: Molly Watt
Anything else
Some of the suggestions I've poked at in the past have always come with added complications. For example, how do we include an accessibility toolbar in a way that benefits the users who need it without getting in the way of those who don't.
The preference has always been to allow users to change website themes based on their own preferences using third-party and browser tools. This has always left a gap on mobile devices and often requires extra digital skill.
Safari Technology Preview has recently added a CSS media query
prefers-color-scheme
which can detect the system-level preference in MacOS Mojave of a light or dark theme. You can now easily write CSS custom to both and the user only has to declare a preference once to affect all websites (providing them adopt it).Adoption and sharing of this by big websites (GOV.UK) will help spread awareness and prompt other platforms to add their own system-level preferences.
Check out a prototype: https://govuk-dark-mode.herokuapp.com. You'll need Safari Technology Preview and MacOS Mojave at time of raising this issue.