Dark theme: improve base color contrast

[fvsch]

Scope: this issue is to decide if a change is wanted and roughly decide what it should be. If we need to proceed with a technical implementation, it should happen with a Bugzilla bug.

The problem

By default, all tools use --theme-body-color text on top of a --theme-body-background color.

In the dark theme, those colors are defined with a kind of medium-gray for the text color, resulting in low contrast:

• 4.48:1 contrast ratio, barely failing the WCAG2 minimum of 4.5:1.
• Low contrast in panels such as the Network Monitor (fixed in bug 1476590), DevTools settings page, and more.

This is what it looks like, with adjusted contrast on the right (using grey-40 instead) for comparison:

The cause

The dark theme defines those CSS variables:

:root.theme-dark {
  --theme-body-background: #2a2a2e; /* grey-80 */
  --theme-body-color: #909090;
  --theme-body-color-alt: #737373; /* grey-50 */
  --theme-body-color-inactive: #b1b1b3; /* grey-40 */
}

I’m not sure what the semantics of the "alt" and "inactive" colors are, but from their names I would expect decreasing contrast ("alt" lower than the base color, and "inactive" lower than both). It's particularly strange that the "inactive" color is the most contrasted one.

Anyway, the main problem is the #909090 base color, which I believe we should bump to grey-40 (#b1b1b3) instead, like we did in the Network monitor, but globally.

Note that a lot of tools define more specific colors for a lot of text, so changing the base color should impact only the settings page, maybe a few tools and bits of text.

I’ve visualized my proposed changes in this image:

These are fairly conservative changes. Compare to the Photon guidelines for text and background contrast, which calls for pure white text on dark backgrounds:

Follow-up work

1. Check the CSS codebase to see how --theme-body-color-alt and --theme-body-color-inactive are used. It could be that the “alt” variant is meant to be used on an inverted background, it which case its current settings might make sense.
2. Try those CSS changes in Nightly and check how they look.

[fvsch]

Here’s a series of screenshots from different tools, with the proposed color changes on the right.

Looks like a good improvement all around to me. :)

[fvsch]

Uses of:

• --theme-body-color-alt: 28
• --theme-body-color-inactive: 12

[fvsch]

One bit of user feedback:

I use dark UIs for every developery thing I do but I always found Firefox’s dev tools very hard to read. And I am not even visually impaired.

If we want to push things even further, we could move up one notch in the Photon grey palette.

I’ve added a more contrasted option (for both dark and light themes), and the WCAG2 contrast ratio for each. Regarding the contrast ratio, note that:

1. The minimum to pass WCAG guidelines is 4.5:1 (AA level; AAA level has stricter guidelines)
2. The minimum is often not very readable! It’s the same level of contrast you get with medium grey text on a pure white or pure black background. Higher contrast (e.g. 8:1) is better.

My final recommendation is to migrate to the values in the third line ("Reordered and stronger contrast"), then to update different tools to harmonize on those values ("base", "alt" and, very rarely, "inactive"; we may need to create a "strong" variant too with the strongest contrast, grey-10 in dark mode and grey-90 in light mode).

[violasong]

Thanks, this is great work! I can't believe I overlooked this AA failure during the Photon redesign since I had done so much contrast-checking of other colors :D. I think the alt/inactive colors just never got thoroughly worked on.

Some background:

• My previous assumption was that users who needed high contrasts would use the light theme, and I considered that the non-official a11y theme. I'm doing more research and just learned about about white screen sensitivity which can make light themes visually stressful for some users.

• An assumption I still hold based on user feedback is that very light colors on dark backgrounds can be too much contrast and also cause visual stress for some users. There have been requests for subtler contrasts as being "easier on the eyes." One use case was along the lines of lengthy code-staring sessions in debugger (which is pretty different from the overall Firefox dark theme use case). Perhaps some of these users work in darker rooms.

• There is a bug filed to allow user-determined theme colors, and that would make it easy to add special high contrast themes. This will be the ideal/eventual solution.

I definitely agree with bringing the dark theme to at least AA contrast with Grey 40. Gray 30 might be too much. However, I realized we can get this to 7.06:1/AAA contrast with the custom color of #B6B6B8, which is just a tad lighter than Gray 40.

I'd love to have a try build with #B6B6B8 as the base, plus the reordered alt/inactive suggestions. It would be great to have some regular dark theme users on the DevTools #general channel trying this out, just in case there are any major issues.

[fvsch]

I'd love to have a try build with #B6B6B8 as the base, plus the reordered alt/inactive suggestions.

I’ll see if I can try that next week.

I also wonder if it might be worth having a separate "high contrast" theme, with mostly pure white-on-black (common for high contrast themes), borders for buttons, strong borders and separators instead of muted ones, etc. With a few adjustments to button styles, it might be possible to activate the high contrast style with CSS variables only.

[violasong]

Great, thanks!

Re: High contrast theme - eventually we want to implement user-customization of themes - once we do that, it'll be a lot easier to support/maintain extra themes like this.

[fvsch]

I started working on this in an existing bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1464348

For now I’m not keeping the suggestion to use #b6b6b8 instead of Grey-40 #b1b1b3 (a 2% brightness increase), because there is a lot of text explicitly using grey-40 already in the devtools with styles like .theme-dark .some-element { color: var(--grey-40); }. I thought it’s best to not create too many shades of Grey 😉.

But if grey-40 is not enough and grey-30 is too bright, we could maybe create an intermediary grey-35 shade, around #c5c5c8. Devtools styles already have some in-between shades of Photon colors (e.g. --blue-55 and --magenta-65).

[digitarald]

An assumption I still hold based on user feedback is that very light colors on dark backgrounds can be too much contrast and also cause visual stress for some users. There have been requests for subtler contrasts as being "easier on the eyes." One use case was along the lines of lengthy code-staring sessions in debugger (which is pretty different from the overall Firefox dark theme use case). Perhaps some of these users work in darker rooms.

@violasong interesting, was that user feedback for devtools? I imagine it might apply more to walls of text, like reading mode.

We already noticed in the past that contrast depends a lot on the screen and applied settings. Maybe part of the thinking here needs to consider testing on low-cost laptop screens (in dark dorms).

[violasong]

For now I’m not keeping the suggestion to use #b6b6b8 instead of Grey-40 #b1b1b3 (a 2% brightness increase), because there is a lot of text explicitly using grey-40 already in the devtools

Ah, yes, that makes sense! We can see how people react to this change and consider making a gray-35 later if it seems like a good idea.

@violasong interesting, was that user feedback for devtools? I imagine it might apply more to walls of text, like reading mode.

Yes, that feedback was for DevTools. It would indeed be great to test this on common Windows laptops - once this is in Nightly we can tweet about it and hopefully have people trying it on lots of different computers.

[fvsch]

Just confirming that the low contrast in Settings, Network monitor and other places was a regression.

Introduced here: https://hg.mozilla.org/mozilla-central/rev/a1e6c367f91c#l4.43

That color change was wanted for Debugger sidebars only: https://bugzilla.mozilla.org/show_bug.cgi?id=1421389#c1

[fvsch]

Closing this issue since the UX need was clarified, and an initial implementation just landed.