Is dark mode / alternative themes a consideration for auditing against WCAG contrast criterion

[dashouse]

Overview

When auditing a website (or app where relevant) are the criterion relating to Text and Non-text contrast passed when met by the default theme alone or should a failure in an alternative themes be considered a failure overall?

Considerations

User opt-in

A user can opt-in to dark mode in multiple ways.

Primarily these are:

• Local setting on website or app - For example a switch that changes the UI theme of the local website only
• Global OS setting - For example setting "dark mode" on OS level and providing alternative CSS via @media (prefers-color-scheme: dark) when available on any website or app

Automatic theme change

A non-opt in approach might be when an OS, App or Website applies an alternative theme based on light conditions or time of day. An example of this might be when using Google maps - The UI will transition from light to dark mode when driving through a tunnel or when darkness falls.

Assumptions

My assumptions are that, providing the method of switching meets Text and Non-text contrast in all themes AND the alternate themes are "opt-in", WCAG criterions would be considered met if only assessed against the default theme.

If themes are changed automatically without user interaction then all automatic themes must be assessed independently.

Any other considerations?

Are there any other considerations for contrast requirements for dark mode considering it is often considered lower contrast and can be used in conjunction with other user settings such as @media (prefers-contrast: more)?

[alastc]

Just to close the loop, the conversation on twitter.

I think a key consideration is whether the dark mode implementation is considered:
a) An alternative version, i.e. the default is the conforming version, and you can get to that easily. Or
b) A page variation, a bit like different levels of zoom.

The first would be effectively exempt, the second you could argue needs to conform.

If the site provided a manual switch it would fall into (a). Without that, and if you have OSes defaulting to changing modes depending on the time of day (e.g. Mac / iOS) then I think it would be (b).

[patrickhlauke]

b) A page variation, a bit like different levels of zoom.

incidentally @alastc this is exactly the sort of thing I was arguing about including in the third note of https://www.w3.org/TR/WCAG21/#cc2 at the time (and not just limiting the wording there to "various screen sizes" alone)

[dashouse]

I think a key consideration is whether the dark mode implementation is considered: a) An alternative version, i.e. the default is the conforming version, and you can get to that easily.

Would you consider a user preference setting at iOS level dark mode with the option to go back and switch it off as something you can get to easily or only when it's available local to that website?

In respect to if the only way you are seeing "dark mode" is potentially via the OS level switch in the first place?

[dutchcelt]

I personally consider Modes and Themes to be two different things. An alternate theme would be exempt, even more so when a user switches away from the default, which is effectively an opt-out. A light and dark mode are variants of the same theme. So this gets a little vague when a mode is a stylistic choice or when it's implemented for the benefit of readability.
The former would suggest it could be exempt, and the latter would require it to be included in the audit. The intent matters here, and to my mind light/dark modes are accessibility options.

[alastc]

I personally consider Modes and Themes to be two different things.

Yes, but the implementations can overlap. You can have a dark-mode which is triggered by the user preference, but also provide a switch to override it.

Personally, I don't think it is clear that users are generally aware of whether they have dark mode on/off, and it can be set at the OS and app level (for added confusion).

So I'm leaning towards it being a page variation (i.e. in scope) unless there is an explicit opt-out (in the "web content") of that mode.

[dashouse]

So I'm leaning towards it being a page variation (i.e. in scope) unless there is an explicit opt-out (in the "web content") of that mode.

I guess theoretically that would mean any audit would be incomplete without auditing dark mode if your website or application changed based on an OS setting without a local switch?

[dutchcelt]

My view is that switching modes manually or automatically doesn't matter, particularly if dark mode is intended for improved reading under certain light conditions. The WCAG documentation should have been clearer here.

[dashouse]

My view is that switching modes manually or automatically doesn't matter, particularly if dark mode is intended for improved reading under certain light conditions. The WCAG documentation should have been clearer here.

I think the nuance here is not that something is the good/right or bad/wrong thing to do, just how it's classified.

I am looking to this from a similar perspective to when something that has very specific rules to meet WCAG criterion - however they can be exempt if other things are true...

e.g. Something that needs to meet contrast if it's the only source of information but not if the information is available in another format - Graph and Table perhaps. Of course there is a right thing to do, but the guidance need to support that not being possible as many updates are made retrospectively.

So related to this, I initially though about it a little like that - Of course you want all mode and themes to be accessible but should it be a requirement beyond the default (or user preferred default)? As the default is available and will still respect other forms of colour overrides such as high contrast mode, colour overrides, inversion, smart inversion, colour overlays etc etc?

However if the suggestion is that it should be considered like a "Page variation" that's great - it's just trying to find clarity on scope for auditing.

[dutchcelt]

It sounds like we're both looking for more clarity that is obviously missing, but possibly for different contexts. So for me, Light/Dark Modes are both in scope when they're provided to aid readability to improve accessibility in various conditions and use cases. And you're correct; I'm looking at the intent as this is often a juridical factor.
Providing a different layout depending on the viewport size is similar. All variations (mobile, desktop, etc.) must be accessible, or I could drop desktop et al. and keep the mobile variant. Just like I could drop the dark mode option.

There is no clear criterion for modes in the WCAG, so this is the approach I'll be taking.
So if anybody has more insight, I'll be more than happy to take that on board.

[patrickhlauke]

if a user can easily switch (with a mechanism on the page) between modes, then as long as one mode is conformant, that will likely count as a conformant alternative.

if the switch into a different mode is automatic/depends on OS settings, then to me it's more on par with different breakpoints based on viewports - not something that a user can just easily toggle (unless they go into their OS or browser settings). in which case it's essential that each mode be conformant.

as said, i proposed early on to make this sort of distinction clearer in the "Full page" definition, but it was abandoned due to increase in testing burden, if I recall correctly. maybe something worth revisiting @alastc

[dashouse]

if a user can easily switch (with a mechanism on the page) between modes, then as long as one mode is conformant, that will likely count as a conformant alternative.

if the switch into a different mode is automatic/depends on OS settings, then to me it's more on par with different breakpoints based on viewports - not something that a user can just easily toggle (unless they go into their OS or browser settings). in which case it's essential that each mode be conformant.

as said, i proposed early on to make this sort of distinction clearer in the "Full page" definition, but it was abandoned due to increase in testing burden, if I recall correctly. maybe something worth revisiting @alastc

Thanks @patrickhlauke - I think this is clear. Interestingly, the reason I framed this around auditing is squarely in line with the testing burden concerns. This is not about making an inaccessible mode, just if it needs to be audited against WCAG.

Obviously the impact could be quite large for internal QA and for external auditors it's another line item to bill for / cost to customer - however I do wonder if there is a sensible approach to auditing dark mode that can take a more broad strokes view of a cross section of pages to make sure the translation of the design has remained intact. It is likely that anyone building a dark mode theme will have some kind of systemised colour mapping from the default theme that would limit the amount of potential issues?

[dutchcelt]

It is likely that anyone building a dark mode theme will have some kind of systemised colour mapping from the default theme that would limit the amount of potential issues?

That's how I've done it: define colour sets and combinations upfront, including the additional colour modes tested using the WCAG levels. For me, that is the only way to keep the testing manageable. Adding additional mode colours to an existing non-moded interface set gets unwieldy very quickly. So it's something I'd only recommend during a redesign phase or in a new build.

What I would consider, as this thread above shows, is to have new modes activated by the user when added to an existing code base. Allowing for the possibility that it becomes less accessible. Maybe with an accessible modal/ notification to allow the user to revert the switch. The effort to make them automatic and compliant could then be done as a separate feature.

Btw. This issue also exists in non-moded pages with colour-inverted panels. So some of the groundwork could be done there.