Is dark mode / alternative themes a consideration for auditing against WCAG contrast criterion #2889
Comments
|
Just to close the loop, the conversation on twitter. I think a key consideration is whether the dark mode implementation is considered: 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). |
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) |
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? |
|
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. |
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. |
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? |
|
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. |
|
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. There is no clear criterion for modes in the WCAG, so this is the approach I'll be taking. |
|
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? |
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. |
To be fair, the original conformance model in WCAG 2.x was setup before media queries were a thing!
Indeed, and it is a tricky area as we balance between:
I think that is the case here. When @patrickhlauke was arguing to include more in the note (as well as zoom), I (and others) weren't clear what the impact would be so wanted to be cautious. For dark-mode specifically, it is something extra you are adding, and the testing burden scales with that extra work you are already doing (which presumably is being QAed anyway?) |
while it increases the testing burden for sure, i think in part "them's the breaks" when properly assessing a site for WCAG conformance. and while yes, sites may offer oodles of customisation options that can lead to a myriad of possible permutations, at least it would be good to officially mention some of the well-known ones (beyond just media queries based on viewport size, also mention how an auditor/company then decides to test this is left up to them (the same way we don't prescribe that they need to test every single possible viewport width/height, though theoretically they should). we found that asking a client during the sales process if they (or, more likely, their development team) are aware of any specific adaptations/breakpoints/versions can help scope out how much extra work may be involved in testing. |
|
Proposed working group answer (revised to address a comment by @patrickhlauke) When a site offers a dark mode theme that users can select to be displayed as default in their browser's settings, this theme counts as an alternative version benefitting some users. It is not by default in scope when evaluating conformance in the same way as different page variations at different view port widths are necessarily included. The rationale behind this is that users having their system/browser set to dark mode is a choice, whereas the viewport dimensions are not necessarily a choice (particularly on smartphone/tablet environments, where this is determined by the device and not something that can be changed easily). However, if an in-page control exists to toggle betwen default mode and dark mode, the dark mode theme may be considered as a conforming alternative version if it improves on aspects of the default version, such as low low contrast of text or non-text content. |
is the rationale behind this that users having their system/browser set to dark mode is a choice, whereas the viewport dimensions are not necessarily a choice (particularly on smartphone/tablet environments, where this is determined by the device and not something that can be changed easily, although less so on desktop/laptop where they can change their viewport dimensions by zooming or resizing their browser window)? it would be good if this sort of rationale could be documented, possibly as an addition/note on https://www.w3.org/TR/WCAG21/#cc2 |
Basically, yes. Should I add this to the proposed WG answer? |
|
@detlevhfischer if you don't mind / if that's acceptable, yeah i think it would help provide clarity to the WG position |
|
The rationale proposed herein regarding choice is flawed in my view. The ability to perceive content with WHCM or a dark theme is not a choice as such. Regardless of whether WHCM or a dark theme are explicitly within the scope of WCAG is largely irrelevant given that many people depend on these features to use the web including myself. An experienced evaluator can identify items that are typically affected by WHCM or a dark theme, remembering that the behaviours of these are platform-specific. For example, in Windows, evaluating whether the checked state of a radio button is visible in WHCM is simple enough, but it is not covered explicitly anywhere in WCAG. It is still, however, a 'critical error' for people using WHCM and switching to a 'standard theme' is not a workaround. |
|
@electronicwoft there's a difference between WHCM and switching to dark mode. WHCM will force/modify colours defined by the author, while dark mode only sets a preference and the author has to explicitly set colours/styles to take effect when this hint is enabled. |
|
a user's intention is surely the same in both cases - to be able to perceive content. The notions of 'preference' and 'choice' obscure the necessity of WHCM or dark mode for some users ... |
|
I guess the key difference here is windows high contrast mode or overriding colour in a browser are all things that need to be supported from the main stylesheet whatever mode it is in. This should be standard practice for any development process or audit. Colour inversion is often done on an OS level so effects the entire display and should "just work" on any website or app. In both of these instances websites colour will change based on these overrides. As dark mode is authored by the developer it's only going to do anything if the website has specified styles for a branded dark mode. I believe this is exclusively where the idea of "preference" as a term comes from as your user settings are effectively saying "I'd prefer dark mode if you have it". If it's not something that's supported dark mode setting would not do anything. So while I think the output can be similar I believe the nuance is around what is causing the theme change? Is it being controlled by the user, operating system or authored by the website you're on? |
WCAG 2.x and dark mode:If a site is using WCAG 2.x contrast math and SCs and is failing in dark mode, then that site is most likely completely unreadable for dark mode. WCAG 2.x contrast math does not provide good contrast when calculating for dark mode, particularly for SC 1.4.3 — A site that is passing WCAG 2.x contrast in dark mode is not necessarily actually accessible. Example:
If light mode is calculated using WCAG 2 to comply with 1.4.3 etc, that satisfies minimum legal compliance as the main view. All other themes are alternates. APCA can therefore be used for dark mode to provide actual accessibility for dark mode, and in fact for other alternate themes. This is important in that it means APCA can be used to create specialty themes such as Daltonized versions to directly accommodate color-vision issues such as protanopia for instance. This alleviates the voiced concerns regarding legal compliance to the old standard versus actually accommodating user needs. It should allow us to gain more insights during the beta program as well. |
|
"windows high contrast mode or overriding colour in a browser are all things that need to be supported from the main stylesheet whatever mode it is in. This should be standard practice for any development process or audit." absolutely agree irregardless of whether WHCM or dark mode are thought of as modes or variations or themes. In terms of conformance evaluation practice, including commonly occurring implementations of "the accessibility features of operating systems, browsers, and other user agents. " should be in scope. As I said above, experienced evaluators will know about any common accessibility issues with WHCM or dark mode. This is not a slippery slope of evaluating endless user stylesheets, but a commonsense decision about determining the extent of what 'accessibility supported' entails (see conformance requirements in WCAG 2.x). In my experience, I have never seen a deliberately implemented 'conforming alternative' version of any web page or application, so, while it might be a (perhaps redundant or anachronistic) feature of WCAG 2.x, I don't believe it is a consideration for scoping an evaluation. And where does the forced colors media query fit here? |
|
|
It seems to me that the proposed WG response does not fully consider the impact on end users of accessing the “conforming alternative”. Consider: I am a user who has my operating system color scheme set to Dark mode because it reduces my eye strain. I encounter a web site that presents me with a “dark” style sheet based on the prefers-color-scheme media query. This style sheet has a number of color contrast failures. This seems to be a clear failure of 1.4.3. While there may be a conforming “light” version of the page, it’s not obvious how this user would know that this alternative exists. It is not linked from the page nor is it available via a toggle or in-content setting. Further, and perhaps more concerning, requiring a user to alter the appearance of their entire operating system in a way that could reduce its usability in order to access this alternative is a tall order. Some users may not even be aware of how to change this setting, having enabled it once during OS setup. Or, to put it another way, one could easily argue that it is the dark mode styles that are required to meet contrast. Opting in to light mode is a user choice, so “light mode” styles are an out-of-scope alternative - users could simply opt out of light mode. |
|
I am leaning toward the following suggestion: If a website offers more than one scheme:
Footnotes: ¹ Just to mention, there are useful reasons to have more than one light mode, as well as more than one dark mode, once you begin to consider different enhancements for contrast and/or color. The point here is that one version, the default light mode, must pass 1.4.3, but we don't want to force the burden of testing by insisting that more than the default must pass, provided that the user can select. Because we want to encourage the development of additional, alternate schemes, we should not require testing alternate user selectable schemes, because that added burden will de-incentivize, with the chilling effect of limiting the development of new alternates. ² There is no point in requiring a dark mode to pass 1.4.3, as this has been established as essentially meaningless for dark mode. At a minimum it would need to be 1.4.6. Even 1.4.6 can be weak here. I hesitate to mention, dark mode might be an opportunity to suggest the use of an alternate and more perceptually uniform math, like BRIDGE. |
|
+1 @electrickite ... it's the conformance of the version that a user of dark mode is using and not some other version that they are not likely to use or find. The notion that authors are overburdened by ensuring that contrast is conforming in so-called alternative versions is a bit old hat in my view given that most web sites and applications these days are platform-based and not stitched together by candellight - making all versions work is a platform decision that is done once, surely? But it's not just about colour contrast. The removal of everything implemented using the CSS background property in WHCM is particularly an issue ... i'd like to see something that makes provision implementing things like radio buttons using background-color or background-image a failure too. |
|
I'm not sure the reality of a platform based approach works like that in practice. I work in the design systems space exclusively in a few places now and day to day it's quite far from that... it's usually the case that you end up with 900 individual web apps all running different versions of the design system, many of which can't or won't update. Public websites often don't use the same tech stack as application journeys etc so there's a big disconnect between browsing and doing. I don't disagree with the sentiment at all, but the reality is that "burden" of QA on more than one mode would likely cost a large org millions - which would ultimately lead to not implementing the mode. The scope of this initial conversation was not if the mode should meet the same accessibility standards, only if it is a requirement to test against. |
This ⬆︎ |
|
all valid points, @dashouse ... to the topic then, testing for identifiable use cases is required regardless of the supposed increased workload. As I said above, there are common accessibility problems that an experienced evaluator can identify in the course of their existing workload. These problems can also just as readily be identified by code-based automated testing (eg: radio buttons and checkboxes that ue the CSS background property, buttons without CSS border properties, etc.). In my view, WCAG has become a technocracy in which there is now an established orthodoxy regarding its scope, value, and purpose. That there is a question about whether to test or not for something that clearly affects a large enough user community adversely suggests that the stated aim of making the web more accessible has become secondry to facilitating legal protections for corporations and increasing the efficiency of testing operations. And, in the case of dark modes and WHCM, the effort is not being put in either by testers or evaluation software manufacturers because WCAG is silent on this issue. |
The 2022 automated test of 1 million websites found that 839,000 sites failed WCAG 2 due to "low contrast", and while there is an argument that these tests are more of an example of how automated testing lacks accuracy (not to mention false fails due to the actual guideline), it also seems pretty clear that site authors are "not putting in the effort." When other errors are also considered, out of the 1,000,000 sites only 32,000 passed WCAG2. How is making things more complicated or more burdensome going to encourage more sites to comply? How is demanding that "everything must be tested to our arbitrary values because we said so" going to facilitate the goal of actual accessibility? For instance, different people have different needs, some of those needs are in conflict with needs of others, creating a blocking accommodation where there cannot be a guideline that meets both. And we're not even beginning to touch on the fact that legislation lags behind technology often by decades. |
|
"How is demanding that "everything must be tested to our arbitrary values because we said so" going to facilitate the goal of actual accessibility? " Who or what determines a scope for testing now? The topic of this thread implies that WCAG is the key determinant, and, if it ain't in WCAG explicitly (or an orthodoxy hasn't grown up around it), then it ain't testted. The absurdity of validating HTML in the past decade for example ... still unfortunately sacrosanct in many circles, but likely to carry sufficient inertia to be something evaluated in years to come. And hanging hopes on 'conforming alternative versions' is a bit of WCAG fundamentalism and might do more to highlight the shortcomings of a 20 year old specification than offer a solution to this problem. Legislation is an empty threat in Australia and is a questionable motivator anyway. Including something in an internationally recognised specification, however, has proved much more effective which is why the accessibility guidelines working group should seriously consider something explicit such as a new success criterion or failure technique, or by extending F3 to cover other UI components and CSS background properties. Unfortunately, WCAG 3.0 doesn't appear to want to resolve any of the longstanding or intractible accessibility problems light colour contrast in WHCM preferring instead to concentrate on scoring and conformance which in my view is more evidence of corporate capture and trenchant technocracy. |
The last I checked, officially Australia is only requiring level A, which doesn't even include contrast. As you're a native, can you describe the actual legal conditions down there? I'm genuinely curious.
As WCAG 3 is indeed going through a lot of changes regarding the conformance model, but there is still a lot of work going on related to contrast. I would very much like to hear about the issues that you are having with WHCM. We have a discussion forum for readability and contrast at the contrast documentation repo here on GitHub. I'd like to encourage you to start a thread there so that we can dive into this issue further as a matter of the ongoing research and study. Thank you for reading. |
|
Hi Corey @electrickite
Do you have any example URLs for sites which have dark-mode color contrast failures? Because dark mode is somewhat under-researched, yet increasing in popularity for a variety of reasons in recent years, we want to investigate problems that users are having with the functionality of dark mode. Thank you |
|
@Myndex Just to clarify - I am mainly concerned with the case where the content author supplies different sets of styles automatically based on a user's color scheme preference. I am not advocating that authors be required to respect that preference. I also feel that sites which present an in-content control or setting to toggle between color themes can claim conformance via alternate versions. The following sites have color contrast issues in their dark theme, and present this theme to users based on prefers-color-scheme without a way to access the light variant. To be clear - the examples below are overall actually quite good in their dark mode themes, but they all have minor failures despite their popularity. Note these sites were all accessed in a "logged out" state.
I also put together a quick set of demo pages showing different variations of these color theme approaches: https://electrickite.org/a11y/contrast-demo/ At the end of the day, I would argue that any styles presented by web authors via prefers-color-scheme or similar automatic methods constitute a page variation and should fall into scope for conformance and testing. |
Hi @electrickite thank you for these!
Definitely fails APCA. As for 1.4.11, it has an exception, if clickable elements are visible such as clickable text... you can make the argument of the little magnifying glass is clickable and and when you click at the cursor comes up and that's bright and easy to see. I'm not trying to pass it I'm just saying I think it might pass 1.4.11 based on the exception.
Ugh. Twitter's a bit weak
GitHub here fails WCAG 2 all over the place. They seem to be making some effort to correct, though I still have many problems here. The only mode that I can use with my vision issues here is dark mode high contrast, and calling it high contrast is misleading; it's barely adequate. The regular dark modes are utterly useless. As are all the light modes.
In this case I don't even see the field you're talking about, anywhere, so I don't quite know what that is, perhaps I have to be logged out.
Nice.
Yes, I think Alastair made the same point, and as I indicated above I agree. Thank you for the URLs. |
|
Lil' note that people involved at organizations mentioned may be passively monitoring this conversation, as it is related to tasks they may directly or indirectly be working on. Also a lil' note that internal advocacy at large organizations with tons of tech debt and ableist attitudes towards color means that work is slow and emotionally charged. |
|
@ericwbailey Thanks for the callout - did not mean to imply anything about these orgs or their efforts, just that they currently have "in the wild" examples of the kinds of issues being discussed. @Myndex said:
Agreed about @alastc 's comment, but this is not my reading of the proposed WG response by @detlevhfischer . Specifically:
Seems to imply that these types of author-supplied styles are alternatives rather than variations. |
|
@electrickite All good, my comment was not directed at you. There is a ton of work to be done over here in nearly every area—color included. I also do not want to downplay the issue of being able to perceive content, nor your experiences with it. I'll go silent on this issue again in the hopes it does not derail things further. Curious where this decision ultimately winds up. |
I am all too aware of emotionally charged issues on this topic. Post edited. |
|
Hi @Myndex ... it's worth noting that the views expressed herein are solely my opinions. In response to your query about Australiaa: The Disability Discrimination ACT (1992) is a piece of federal legislation that - as the name suggest - covers matters of disability discrimination, but only in certain qualified domains such as education, employment, and obtaining goods and services. The Act requires that, initially, complaints relating to discrimination on the basis of disability in these domains are lodged with the Australian Human Rights Commission (AHRC). These matters are then assessed by the AHRC and may progress to a mediation phase, but only then proceeding to the Federal court if mediation is unsuccessful. In research I conducted in 2018 using AHRC data, only roughly 3% of the complaints that have been made about the accessibility of "online" services progresss to mediation and then only a handful are heard by the Federal court. At that time, there was roughly one complaint made to the AHRC every twelve days. There are also analogues of the AHRC in each of the eight state and territory jurisdictions, but I don't have data for these (there's a PhD topic for someone!). In the AHRC data, about sixty per cent of complaints are made against companies with the remainder being governments and education providers such as universities. The Australian government 'endorsed' WCAG 2.0 in 2010, and introduced a program called the Web Accessibility National Transition Strategy (WANTS), which 'required' that certain digital assets managed by government agencies conform to WCAG 2.0 Level AA by the end of 2014. In my experience, the program generated much interest, but resulted in lots of busy-wortk with little long-lasting structural or cultural change in the ways that government agencies delivered digital products. It did, however, put digital accessibility on the agenda in Australian government and there were measurable accessibility improvements in publicly-facing web sites (which was happening with new technologies anyway), but web applications and/or internally-facing digital systems remain largely inaccessible/non-conformant. There were no consequences for not conforming and the program was under-resourced and lacked executive support, coherence, and coordination so many agencies confected exemptions or simply ignored it. The Digital Design Standard (DSS) was introduced in 2016 for Australian government which still requires web sites and applications to conform to Level AA of WCAG 2.0, but there is no recent or updated requirement as far as I am aware. As far as I understand, in Australia, there is no linkage between WCAG and any instrument legal or otherwise that obliges any entity to conform to the former. Like in so many other ways, Australia is dependent on what happens in the northern hemisphere, and, with the linking of WCAG with other instruments in the U.S. and Europe, accessibility seems to be gaining greater inertia in digital communities in this country. Australia's largest telecommunications operator, Telstra, is midway through making its publicly-facing digital assets conform to WCAG 2.0, many banks have large professional accessibility teams and offer accessible web sites and applications, and there is greater coordination among accessibility professionals across the country. However, government and certain sectors and professions such as health and legal services persist with attitudes and ways of working that are digitally regressive with little hope of change mostly because there is little impetus and certinly none legal. |
|
Hi @Myndex , "I would very much like to hear about the issues that you are having with WHCM. We have a discussion forum for readability and contrast at the contrast documentation repo here on GitHub. I'd like to encourage you to start a thread there so that we can dive into this issue further as a matter of the ongoing research and study." Thanks very much for bringing my attention to this - I will have a read and get involved. |
Thank you very much for this detailed and nuanced law review. Simply reading some of the statutes lacks the texture of your perspective, and it is very helpful to hear the inside scoop from your perspective. Thank you, I look forward to seeing you in the forum. |
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:
@media (prefers-color-scheme: dark)when available on any website or appAutomatic 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)?The text was updated successfully, but these errors were encountered: