Open querkmachine opened 2 years ago
querkmachine
commented
2 years ago Note that this seems to be different to "Auto Dark Theme" on Android Chrome — Chrome itself seems to consider them different, at least.
None of the detection or opt-out methods listed in that blog entry worked when I tried them on desktop Chrome.
vanitabarrett
commented
2 years ago This feature automatically modifies the appearance of webpages in order to create a "dark mode" version. This is done even if the page already supplies a "dark mode" via the prefers-color-scheme CSS media query. It also appears to ignore the color-scheme property.
@querkmachine Is this something that's in our control to fix (by changing CSS within govuk-frontend), or is the only thing we can do here raise bugs with Chrome? Just trying to make sure I understand fully.
querkmachine
commented
2 years ago @vanitabarrett As it stands, I've not found anything that indicates we can resolve these issues. Given it's still an experimental feature that might change in future, but we might want to direct some of these issues to Google in the interim.
Since Chrome version 78, Google has included an experimental feature in the browser, initially named "Forced Dark Mode" and, as of writing, named "Auto Dark Mode for Web Content".
This feature automatically modifies the appearance of webpages in order to create a "dark mode" version. This is done even if the page already supplies a "dark mode" via the
prefers-color-schemeCSS media query. It also appears to ignore thecolor-schemeproperty.The flag comes with several different "enabled" modes (as of Chrome 99), which modify how Chrome is internally applying changes. Each mode results in subtly (sometimes radically) different resulting colours.
Most of these modes appear to work by first overriding neutral light background colours (such as white and light greys), and modifying any copy that it detects as existing on a modified background colour to maintain suitable contrast. Most other colours appear to be left intact. This method of alteration means that colours are not all modified in the same way:
$govuk-brand-colorin mode 1, for example, is unmodified when used as a background or border colour (#1d70b8), but is changed when it is used as a text colour (#61a1ee).Mode 4 appears to simply invert all colours on the page, regardless of usage.
I'm not sure how mode 1 is different from the others. It may be that this is an "automatic" mode where Chrome tries to determine which of the other seven modes works best for the given page and uses that one.
We have received at least one bug report raised by a user who was using Chrome's Auto Dark Mode feature for accessibility reasons (to make content easier to read with cataracts).
Steps to reproduce the issue
In Google Chrome, go to
chrome://flags/#enable-force-dark(this should jump you straight to "Auto Dark Mode for Web Contents") and enable the flag.Actual vs expected behaviour
Currently, a number of these modes produce colour combinations which fail the contrast requirements established in WCAG 2.1.
Below is a non-exhaustive subset of issues currently identified in Auto Dark Mode.
Text inputs and textareas
Text inputs are displayed with a grey background and black border in modes 1, 6, 7, and 8. This fails to meet the expected 1:3 contrast ratio for UI elements (at 1:1.68).
They are displayed with a light grey background and white border in modes 3 and 5, which easily meets contrast ratio expectations.
They are displayed with the default white background and black border in all other modes.
Input prefixes and suffixes
These are difficult to read in modes 2 and 4, where they are black on a dark grey background (1:3.23).
These are much more difficult to read in modes 3 and 5, which renders it as black on an even darker grey (1.22).
These are displayed with adequate contrast in other modes.
Checkboxes and radio buttons
The border and selection states of checkboxes and radio buttons do not have sufficient contrast in modes 1, 6, 7, and 8 (at a pretty much imperceptible contrast ratio of 1:1.04)
They are displayed with white borders and selection states in all other modes.
Select
In modes 1, 6, 7, and 8, select boxes are rendered with a dark grey background and dark grey border (1:1.04).
They are rendered with a black background and white border in all other modes.
Skiplinks
In modes 1, 2, 6, and 7, skiplinks are rendered as white on focus-colour yellow, which does not meet contrast requirements (1:1.34).
In mode 4, it is white on light blue, which is also below expectations (1:3.24).
In mode 8, it is white on focus-color yellow, but additionally has a black text shadow/stroke effect applied, which makes it difficult to read.
This is displayed with adequate contrast (albeit, in white on brown) in all other modes.
Iconography
Most iconography fails to meet contrast requirements in virtually all modes. This includes:
Other components
The good news is that, for the most part, the majority of other components we have in GOV.UK Frontend are not as badly affected as those above, with various components such as Inset text, Error summary, and Notification banner maintaining their necessary visual presence and suitable contrast even with modified colours.
Environment
The results specified here were taken in Chrome 99, running on macOS 15.3, whilst the operating system was set to light mode.
Interestingly, Chrome DevTools does not give any indication that a change to the page's appearance has taken place. All HTML and CSS content, including the user agent stylesheet, computed styles, and those returned through JavaScript, appear unmodified and are not aligned with the page's actual appearance when Auto Dark Mode is enabled.