Dark mode toggle design

[hedgefield]

Just to carry this one over from WordPress/twentytwentyone#622 (comment), I'd like to explore what the nicest toggle design would be. To reiterate: it has to be minimal to match the TT1 style, and fully accessible. I also feel like the sun/moon analogy is an accepted pattern for this feature by now so that it could be understood without labels, but any extra affordances that are possible are always good.

@aristath showed a few examples, and I quite like these:

https://codepen.io/lucas-labs/pen/wvBvEZq
Very clearly shows that clicking on this thing will move from one state to the other. In our case, I'd switch the icons, not rotate the arrow, so that the LTR/RTL reading direction is always consistent.

https://codepen.io/sandeshsapkota/pen/xxVmMpe
I like the iconography and simplicity of this one. I maybe wouldn't make the animation so outspoken, and this one could really benefit from a subtle label below it. For a11y though, the label shouldn't change content, so then it gets a little trickier. What do you call it? It's not a theme. Not exactly a color scheme. Maybe just "Toggle dark mode"? As we can consider the light mode as the 'default' mode, dark mode is the special sauce.

https://codepen.io/sheelah/pen/dEmyqx
This feels like a solid basic option too. It's very clear, simple control state. It's not as sexy but it sure works.

I think my preference would go to the second one with a label. What do you think @melchoyce?

Regardless of the exact design, I've heard several people mention it should probably be at the top of the page, and I agree. Something that touches the meta of a site, like nav, language, currency, or dark mode, feels like it should be at the top. Maybe indeed as part of the menu as @aristath suggested?

[aristath]

Thank you for creating the issue @hedgefield and for carrying the discussion over! 👍

I too think that putting it on the top would be better. The reason I chose to put it on the bottom now is because until we make a decission, the bottom is safer and doesn't interfere with the overall design of the site. On the top we've got the header, the mobile-menu toggle etc, so it's just easier to put it in a dead-zone like the bottom-right.

https://codepen.io/sheelah/pen/dEmyqx
This feels like a solid basic option too. It's very clear, simple control state. It's not as sexy but it sure works.

Yeah, that one is a solution that can work everywhere. We can inject a sub-footer (for lack of a better word) with that toggle. It would definitely be the most accessible and "safe" option.

I think my preference would go to the second one with a label

The only reason I don't particularly like the single-icon approach is because it's not clear that it's actionable. However, if we add a label as per your suggestion then it would definitely be a solid option (and pretty too 😉)

Maybe indeed as part of the menu as @aristath suggested?

For context, in a slack discussion, it was suggested that the toggle can be injected in the actual menu of the site, as the last item (see https://livecodestream.dev/post/2020-08-06-a-better-approach-to-dark-mode-on-your-website/ for an example).

[afercia]

Thanks for creating this issue.

I'd like to remind everyone that the "Switch toggle" controls have been discussed at length in the context of the Gutenberg project because they bring in some inherent accessibility issues that need to be addressed. Even if these toggles are technically implemented with a native checkbox and a properly associated <label> element, there are concerns related to the visual side of the toggles.

In a theme that aims to be WCAG "AAA ready" it's probably worth considering to use another control rather than a switch toggle. I'd like to stress that the AAA level requires the most advanced level of accessibility thus any interactive control needs to be understandable and operable by all users.

A bit ironically, the current toggle (same for the Gutenberg toggle) is more accessible for blind screen reader users than for sighted users.

For blind screen reader users:
Under the hood, the toggle is a checkbox with a properly associated label. Unstyled, it would look like this:

This works perfectly for blind users.

Aside: the verb "Toggle" should be avoided because it's difficult to translate. See WordPress/twentytwentyone#526 and https://core.trac.wordpress.org/ticket/34753

For sighted users:

This is how the toggle looks when styled:

Visually, the main problems are:

• there's no visible <label> element
• the toggle state is not clear: the "knob" position isn't sufficient to clearly communicate the state to all users and this was the main point discussed on the lengthy Gutenberg related discussion

Visible label:

• It's not clear what this control purpose is. Even adding icons wouldn't be sufficient because icons don't have a universal meaning. Level AAA implies the highest level of accessibility, which means this control need to be understandable and operable for all users. For example:
  • users with cognitive impairments may not be able to understand the control's purpose even if it had icons
  • speech recognition software users need a visible label to be able to voice an appropriate command

Indication of the state:

• It is worth noting that even the Material design (which doesn't shine for accessibility) recommended for the old version of the toggle to use "On" and "Off" text on the sides of the toggle to represent the state. In the new version, Material design deprecated "On" and "Off" but made very clear that the toggle state must be represented in a textual form somewhere, either via the label or via some other text.
• The knob position isn't sufficient to communicate the state: does "left" mean On or Off? Or is it right? It is true that the theme changes mode immediately when the toggle is ... toggled and the change is very evident but that clarifies the subsequent effect of a state change. The initial state is still unclear.
• In Gutenberg, the accessibility team strongly recommended a textual representation of the state and in a first moment the "On" and "Off" were tried.
• Important note: the "On" and "Off" can be aria-hidden because they're only meant to represent the state visually
• In a second moment, the Gutenberg implementation of the toggle opted to use an additional text below the toggle to represent the state. Here's how the Gutenberg toggle looks like (including the focus style)

I'm not suggesting to use the same solution but a some text to visually represent the state is necessary. Worth noting the Twenty Twenty-One toggle implementation come from this one: https://codepen.io/waynedunkley/pen/YybgGo which does use some text to represent the state (see "AM" and "PM"). Also the third example linked bt @hedgefield has visible text to clarify the state (though it's not fully accessible for other reasons): https://codepen.io/sheelah/pen/dEmyqx

Overall, to declare this toggle "AAA ready" I'd strongly recommend to add some textual representation/better indication of the state.

[afercia]

Regarding the toggle placement:

it was suggested that the toggle can be injected in the actual menu of the site, as the last item

I'd totally agree placing the toggle in the top part of the page would make sense. However, placing it within a <nav> element would be odd and not semantical: a <nav> element should contain links (or also a heading or text as long as they're related to navigation) and not contain buttons that "do something".

[hedgefield]

Thanks for the important context @afercia! I like that codepen you linked also - though I had it bookmarked because it's one of the few that does it with CSS only ha. But it does give a nice example for the label. Putting "Dark" and "Light" on the side of the control could make it pretty lightweight. So just "Toggle dark mode" as label is not enough for AAA if I understand you correctly? It has to have both states spelled out?

I'm thinking of three different combinations we could try:

1. One classic accessible toggle, with labels on the sides.
2. Same toggle, but with a label that describes what it is, and the side labels referring to the state
3. Same idea as 1, but instead of a regular toggle it's the shifting sun/moon icon. The loss of indication for which side is enabled could be fixed by setting one of the two labels to a larger font size or all caps perhaps?

[afercia]

One more alternative: a toggle button (that is a button with a pressed state). See https://inclusive-components.design/a-theme-switcher/

It's a very long article and the implementation is made with React but it can be done with vanilla JavaScript. Example of the two states visual:

Re: the labeling (the button text): it's good that there's a "fixed part" to communicate what the button is about and a dynamic part that communicate the state with text, besides the inversion of colors.

[hedgefield]

Ooh I like that one a lot too! Better than any regular toggle, maybe not as nice as a dynamic icon + label, but certainly something that fits in the theme's aesthetic.

[aristath]

Ooh I like that one a lot too! Better than any regular toggle, maybe not as nice as a dynamic icon + label, but certainly something that fits in the theme's aesthetic.

Agreed. I already started working on it today on #2, I'm hoping I'll have it ready by tomorrow 🎉
The only "problem" is that it's relatively bigger so I'm trying to see where it will fit in the page's design (perhaps the bottom-right is not such a bad idea after all 😅)

[aristath]

The button implementation was done in #2 and merged.

It now gets injected after the logo/sitename and before the main nav, so it's properly positioned in the tabbing-order.
It's no longer fixed to the bottom-right but instead it's relatively positioned in the header:

The fixed-bottom implementation wasn't trashed, it's still an option by changing this line from relative to fixed-bottom:

twentytwentyone-dark-mode/functions.php

Line 214 in b8c4153

function tt1_dark_mode_switch_the_html( $classes = 'relative' ) {

[hedgefield]

I like that, nice work! I wonder if it might fit in slightly better if the default and hover states were reversed, but also, that risks the ghoOost button problem. This is great :)

[melchoyce]

Looking through a bunch of articles and documentation for OS', it looks like "Dark Mode" is the standard terminology — can we update it to:

Dark Mode: On
Dark Mode: Off

[aristath]

Makes sense.
Done in fa42dcc 👍

[melchoyce]

Super minor, could you add a space between Mode: and On/Off?

[aristath]

Super minor, could you add a space between Mode: and On/Off?

Done in ab1b64f 👍

[melchoyce]

Thanks!

[aristath]

Closing this one since I think all items reported were already fixed. For any new issues please create new tickets. Easier to track and fix if they are separate 👍