Automatic and Accessible Dynamic Themes With OKLCH Color Space

Hi, everyone. Welcome to React Advanced. And today, let's talk about building accessible and automatic dynamic themes using Ocale CH ColorSpace. But first, a few words about me. My name is Nina. I'm an engineer at Evil Martians. We're engaged in product development for large companies and startups, and we also actively build our own open-source products.

So, what is a dynamic theme exactly? Dynamic themes allow users to pick the main colors of the interface themselves. How they do it can differ. It might be something playful like a color slider on this demo or just a set of defined options like we have on GitHub. Let's use the UI to a theme that they like. The main idea stays the same. Users can personalize the look and feel of the product with colors that suit their style or preferences.

Sounds cool, but is it just an aesthetic gimmick or something more? Why do people even need dynamic themes? First reason, it makes the product feel more personal. When people can choose their own colors, it feels like the app is theirs. The personal touch helps users feel more connected and keeps them coming back. It turns the application into something that fits their vibe and not just a generic interface. And by personalizing the product, users bond with it. And it's proved by many studies. Think of it as an extra boost of engagement that can help keep people around and make the whole experience more enjoyable.

The color scheme isn't just a small detail. It sets the tone for the entire interface. The second reason why we like dynamic themes is because with them, everything stays visually in sync. Dynamic themes make sure your UI always looks put together. Whether it's buttons, banners, or whole sections, colors just match the overall vibe so nothing feels out of place. Look at this redecoration of the promo banner. From beach theme to dome theme just in a second. The theme is just adjusting to the colors on the image that you give. Pay attention on how everything stays visually connected while also changing. The last reason to start loving dynamic themes, it's an easy win that makes your product stand out.

Not that many products do this really good. So adding dynamic theming can instantly make your product remarkable. And the best part? It's pretty simple to implement, especially compared to the value it adds. It's so lovely, but if it's such a cool thing, why dynamic themes are still such a rarity? And the answer is color spaces and how color perception works in them. Most of the color spaces don't work well when it comes to color modifications like making colors lighter or modifications like making colors lighter or changing the hue for a new theme. And I'll show you why.

First, let's take a look at the most popular color formats, RGB and HEX. The color format RGB uses three numerical values from 0 to 255 for each color channel. HEX uses a six-digit hexadecimal code, each containing three numbers that represent the amount of red, green, and blue. RGB and HEX are not convenient for color modifications, which are necessary for building dynamic themes. Because for the vast majority of humans, it's difficult to intuitively set colors by changing the amount of red, blue, and green.

Look at this example. Can you figure out how should you change this HEX value to receive the lighter shade of green or a more saturated version of green? In reality, it's very hard and we can't stably rely on it. Look at this slide. Here you can see different shades of green and their representation in RGB and HEX formats. Do you understand how you need to change the value to make a specific color one step lighter or darker? I personally don't. Let's take a look at another one popular color space. HSL is a format that is much closer to the way people naturally think about colors. But it's actually also not great. HSL contains three numbers to encode hue, saturation, and lightness. HSL tries to be more intuitive, but in reality, it is a deformed color space and it can't be used for proper color modifications. It's better than RGB, but it still doesn't guarantee colors will look equally bright or readable after color modification.

Here is an example. That's a hue lightness slice of HSL and for conversion KLCH color space with the same chroma and black and white versions below. As you can see, HSL lightness is not consistent across hue axes. Different hues represent different real lightness values. This leads to issues with contrast and bad accessibility. But KLCH lightness, on the other hand, is consistent and ensures accessibility. That's why KLCH is our choice for dynamic themes.

Let me say a few words about it. KLCH is a relatively new color space designed for perceptual uniformity and it's perfect for creating dynamic themes, as color modifications are extremely simple with it. Despite it's quite new, it can be used in all modern browsers. Here is a more detailed explanation of each KLCH axe. L lightness is perceived lightness. It ranges from 0, which is black, to 1, which is white, or from 0% to 100%. C is chroma, the saturation of color. It goes from 0, which is gray, to infinity. In practice, there is an actual limit, but it depends on the screen's color gamut. H is hue, hue angle. It goes from 0 to 360, red, which is 20, yellow, which is 90, green, 140, blue, 220, purple, 320, and then back to red. And A is alpha, is opacity. It goes from 0 to 1, or from 0% to 100%.

Here are a few examples of KLCH colors. Bright ones, black, white, gray. With KLCH, you can tweak hue, lightness, or chroma and be confident that the result will stay balanced, accessible, and visually coherent. And compare it to hex. The values look like the magic constants. We hardly can understand that the second value is just a brighter shade of blue. Unlike RGB or hex, KLCH is human readable. You can quickly understand which color and KLCH value represent simply by looking by these numbers. Now, let's talk about accessibility. HSL is bad for color modification.

In HSL, hue changes to accessibility issues from low contrast. KLCH works like HSL, but it encodes lightness better than HSL. KLCH uses perceptual lightness to prevent unexpected results, and accessibility issues. But enough theory for now. Let's see how it works in practice, and how we can implement dynamic themes in our application. We will use KLCH along with CSS, just for simplicity. You can build your dynamic themes with any other CSS framework, there is no problem in it. And even using RGB.

Although, we don't recommend this color space. And the first step towards integration of dynamic themes is switching from spectrum based classes of CSS, like text 500, to semantic classes, such as text primary 500. Important here is that it should be part of your pack as a designer. Any color that we add to the project needs to be semantic. And on Figma layout as well. The semantics of names is an important thing. It helps to define the role of color in the application, and to understand it automatically while reading the code.

Now, that in dynamic themes, not every single color in the interface should be customizable. Some colors need to send signals to users, like errors which need to scream in red. Or warnings that wave a yellow flag. We would still recommend naming the signal colors, not just text red, but text error, for instance. But the color that tailwind CSS suggests us out of box, as a static palette, is not enough to build a full palette for dynamic themes. Now, I'll show you how we can build our own palette with the KLSH color space, and with maximum consistency between colors. Here, we need to define two things for our palette. The set of lightness values, and the set of chroma values. Because the hue is either set by you, when you build the theme, or chosen by the user, using hue picker, that's already one part done.

Let's start with the lightness. In tailwind's default palette, there are 11 color steps, from lightest, which is 50, to darkest, which is 950. To define the lightness value for our KLSH palette, we can create a similar step by adjusting the lightness value from 0% to 100%, instead of 50 to 950. Instead of trying to calculate lightness values with some formula, we'll just merge them visually to tailwind's defaults. Because trusting your eye sometimes gives even better results as enforcing the math.

It takes some time, but here is a result list of lightness value we'll use for 11 shades. This gives us our custom dynamic palette the same feel as tailwind CSS build 1, but with more control. Now, when we have lightness values, we need to define chroma, or saturation, for our palette. So, then, we can apply to the KLSH formula, and let the user pick any desirable hue. This step is more tricky than matching things visually, but here, it comes to the KLSH site to help us.

Go to KLSH.com, and first, set the hue that you want. We picked purple, 320. For the lightness from the array that we defined, here is 0.4689, I picked one from the middle, and then we go to ChromaSider. We need the highest chroma value that still covers the full hue spectrum without gaps. Gaps mean some hues won't be available, and will fall back to the nearest colour, which can cause inconsistencies. You need to find a chroma level with full hue coverage, like the one on the screenshot, and then we note it down. Here is a video, and I show how I do it.

First, I check the desirable hue, and then I'm putting the lightness that we've chosen before from our array. Then, I'm changing the chroma, paying attention to the hue axe. First, there are gaps. I change it back. Now there are no gaps, and I can pick this value of chroma, and avoid visual inconsistencies. As a result, by repeating it with all our lightness value, we get an array of chroma values, and this palette is very consistent.

Now we have both chroma and lightness, and by writing the values from these arrays, we can apply it to any hue that we want, or the user wants. Everything that remains is a pretty theme colour picker, but what is a more appropriate way to display it? There is a native solution, a regular old input type colour, but it's not suitable for our case. It allows users picking all colour components, which means both hue and lightness and chroma together, which might puzzle the user.

We just want to allow a user to pick hue. Especially for solving this problem, at Little Martians, we developed an open-source colour picker that is called Simple Hue Picker. It's a lightweight and framework-agnostic library. Look how this hue picker works. It works like a charm. Here, the user just picks the hue that they want. By the way, if you take the same hue set as Tailwind CSS palette has, and compare your results in Dynamic palette with the static one from Tailwind, there will be not a big difference at all.

After we created a custom colour palette, agreed with the designer on the names of colours, and assigned semantic names to signal and brand colours, our next step is to transfer all the new colours for dynamic themes into our Tailwind CSS configuration file. Or, again, we can do exactly the same thing using other CSS approaches. For example, in CSS models, it will look like this. We're basically finished. Our final step will be to reveal the secret, how we can deal with all the colour calculations to make our theme to make our theme change in life. For all the colour calculations, we use the Colory Library. It's a super useful tool for any types of colour modifications. Check it on GitHub.