Disclaimer

This is not an excuse to bully or deride requests for communication and progress on accessibility needs. Do not tone police people asking for these things, please.

Dark Mode and Accessibility

"Dark Mode" in specific is not something covered by most accessibility guidelines directly, because there is very much no one-size-fits-all design criteria. In general, you should be making it possible for users to personalize the styling of your website (or software) to fit their needs. As long as you are not blocking users from being able to make those changes, you have done your duty from a legal and international standard perspective re: Dark Mode.

Of note: providing your own dark mode can actually be an issue, because you are now responsible for making it work with all color-related success criteria in addition to whatever the default theme for your site is.

Customizable interfaces are an accessibility feature, but not an accessibility requirement. For some, dark modes are actively harmful too.

I was already at Discord when we pulled a rather infamous April Fools’ prank where we discontinued the light theme. Like, pulled it from the app for a full week. We rode that bit.

And people screamed. People screamed a lot. I still worked in customer experience at the time, I would know, I was fielding a lot of the anger. And of course I couldn’t meaningfully do anything about it, but users would yell and scream and tell me that I, personally, was causing them to have unending migraines and eye strain and that I worked for an ableist company and that if I couldn’t flip a switch to magically bring back light mode right now then I was clearly doing harm towards disabled individuals.

Bolstered by user outcry, a few folks on the design and engineering teams crunched to make a better light theme. They did it in their spare time, because they thought it needed doing. They crunched, we shipped it, the outcry stopped. But they were 4 or 5 folks out of 200, and they were doing this at 10PM, 11PM at night, during an already-crunchy period for us.

I’m glad they took that time—the users expressing their pain weren’t lying about it, dark mode was actively harmful for them to use. To the majority of the company their pain was incredibly easy to dismiss—and you might be quick to think, “well that’s really shitty,” but hang on now.

When we pulled light mode from the app, the outcry was met with positivity from those who found our light mode to be utterly unusable. Both internally and externally. When I saw user pain about light mode dismissed, it was from a place of, “well light mode gives me migraines! light theme is inaccessible for me!” Because it’s true—light themes on software do cause migraines and eye strain for some just like dark themes on software can cause migraines and eye strain for others.

This is precisely why WCAG has not codified light vs dark in its guidelines. WCAG standards are designed to address the broadest possible group of needs using data-driven standards that make it easier for folks across the ability spectrum to use software. The trouble is that ability status is immensely personal—in attempting to craft standards for a broad spectrum of needs, you can’t address each and every personal experience, and because ability is a personal experience, and everyone’s’ bodies are different, some folks are always going to need individualized options that aren’t necessarily possible or easy to standardize or implement at scale.

The fix there, of course, is offering customization and the ability for someone to drive, but… given it took us 7 years to ship customizable color themes and even then they’re highly limited, I can say from personal experience that it’s not as easy as it sounds.

To muddy the waters even further, "needs bright white on dark dark" and "needs dark dark on bright white" are not the only two options. Many people with astigmatism (hello) would be best suited by a lower-contrast theme, except it also can't be too low contrast because that's a population that also has a lot of refractive error and you still need to be able to see the screen elements.

One of my Tumblr userscripts changes the background to "old blue" (=Tumblr's vintage color scheme) for this exact reason—the inbuilt low-contrast theme is too low-contrast for me (posts are the same color as the background) and it's hard to make out text. With a combo of old blue and a darkened screen (which, as it is LCD, has lighter darks inherently, and this one in particular also has shit gamma), I can comfortably browse the site.

But wait, Innes, your setup is an almost complete WCAG fail! It only passes AA for large text and graphical objects!

Sure.

But two things to consider: first, from the website's perspective, only the shade of blue has changed.

But also, if we were to imagine a system where contrast ratios took screen brightness into account and pumped up the contrast to maintain the WCAG standard, then perversely, passing WCAG contrast standards would make it less accessible in this instance for the intended user, who is me.

And this is a very real thing in accessibility—there is no perfect solution for everyone at once. For example, Cohost's default font is Atkinson Hyperlegible, a font designed to be legible for people with low vision while still being aesthetically pleasing, which a friend of mine commented on recently because he found it... hard to read.

This happens in physical spaces, too. One person needs a service dog to avoid becoming seriously ill and another is allergic to dogs and will become seriously ill if exposed to one; how do you accommodate both of them independently showing up to the same event? What if instead of an allergy, the second person has PTSD triggers associated with dogs? Do you handle that differently from the first scenario, and if so, how?

This is not to say that we shouldn't strive for accessibility. But everything is a tradeoff.