Proposal: a new color palette for WordPress

Just like my previous posts on type scale and spacing, a standardized approach to color enforces consistency and simplifies decision making for UI design. It can also make it easier to adhere to web accessibility guidelines. This post aims to point out the opportunities we have today, propose a new color palette, and suggest how to implement it.

Why a new color palette?

Our existing documentation on color provides a lot of wonderful color options. Since their introduction, these colors have had a huge impact on WordPress. That being said, here are some opportunities for improving the current system:

  1. Predictable accessibility: Aside from Base Gray and Accent Red, none of the base colors pass contrast guidelines against white text (a common use case).
  2. Balanced number of color options: We can improve the balance between having too many options and not enough.
  3. Consistent visual weight: Each hue should have a similar visual weight when compared to other hues.
  4. Easy reuse of colors: By using variables, we can make things easier for us and also provide benefits to the end user. This includes easier maintenance, custom dashboard schemes, dark mode, and more.

Color proposal

My proposal focuses on five main hues — Gray, Blue, Green, Yellow, and Red. These are by far the most used colors in WordPress and the most important to get right. The current color system has accent hues like purple and orange. These are nice to have but aren’t the focus of this post. If a new hue is needed in the future, a solid color system should be able to expand easily.

You can click on the image below to enlarge, or visit this CodePen to see a live example.

New proposed color palette

Gray is used for neutral colors, like text, backgrounds, and borders. Blue is primarily used for interactions. Red, Yellow, and Green are messaging colors used to indicate error, warning, and success respectively.

The new grays were inspired by the original set, with a slightly cool tone. Blue is now a bit closer to violet, which is similar to the new button color introduced in WordPress 5.3. Red, Yellow, and Green have been optimized so that messaging is clear.

A before and after comparison of a button with new colors applied.

Generating colors programmatically

These colors were selected by using the open source Color Studio tool. It uses a modified version of Lyft’s ColorBox algorithm under the hood, which is a powerful way to generate light and dark tints programmatically. Color Studio is unique because it allows you to manipulate color more holistically, resulting in colors that are consistent and vibrant.

Typically when you simply lighten or darken a color, the results can be muddy and inconsistent across different hues. When you try to apply that same method to every hue, it can quickly become hard to manage.

Take blue and yellow as an example — at the same level of lightness, yellow appears lighter than blue.

Blue: hsl(240, 100%, 50%)
Yellow: hsl(60, 100%, 50%)

Color Studio can help with this, by making the colors more perceptually uniform.

Accessibility

In the context of color systems, accessibility should be simple and built-in.

The colors in this palette contain 12 values from 0 to 100. White and black sit outside those values. Black text is WCAG AA accessible on colors ranging from 0 to 40. White text is accessible on colors from 50 to 100.

A range of 12 gray colors named in sequential order from light to dark (0, 5, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100).

By using this system, you don’t have to use a contrast tool when you come across a color name. For example, you’ll know that Blue 10 is a very light blue and it’s accessible with black text. If you see “Red 50” you’ll know that it’s accessible with white text.

Blue and Gray have some additional benefits that make accessibility even easier. Gray 50 and Blue 50 pass WCAG AA for text (1:4.5) on both white and Gray 0 backgrounds. In WordPress, it’s very common to put gray text on a light gray background, so this was important to get right.

These designs adhere to accessibility guidelines on both white and light gray backgrounds

Additionally, the borders used in this example pass WCAG AA for non-text contrast (3:1) on both white and Gray 0 backgrounds.

Applying the new palette

I’ve implemented this new color palette in the Design Experiments plugin to get a sense for how it looks in the UI. I was able to replace every color with the nearest equivalent color in the new palette. This was a rough implementation, but it’s a close approximation of how the UI would look with these new colors. Note, the experiment is now out of date since the update to buttons and controls in 5.3.

Additionally, I was able to greatly reduce the amount of unique colors for text and backgrounds by about 60%. And this doesn’t even include the block editor.

Here’s a quick before/after gif (pre WordPress 5.3):

Before and after images of WP Admin dashboard with new and old colors.

Or, if you’d prefer, here are two static images that you can switch back and forth:

You’ll notice that the difference is subtle. This is intentional. The new palette is designed to be compatible with the existing UI.

Here are a few more examples of how the color palette can be used:

Naming

How these colors are named and used by designers and developers is crucial to the usability of the system itself. By naming colors clearly, they can easily be identified by their purpose. For example, Accent Red and Accent Green don’t describe the colors’ purpose. On the other hand, Error Color and Success Color help limit the intended scope of the colors and describes their purpose. Communication over decoration. Here are a few suggestions I have for naming:

  • Primary (Blue): Focuses attention. Use on buttons and other UI controls.
  • Error (Red): Communicates status and draws attention towards critical elements. It can signify destructive actions.
  • Warning (Yellow): Communicates status and draws attention towards non-critical elements.
  • Success (Green): Communicates status and signifies positivity or success.
  • Neutral (Gray): Used for neutral elements in the UI. This can include navigation, text, borders, etc.

Implementation

Having all of these colors is great for flexibility, but realistically only a handful of shades will be used in the WordPress software. By including only what is essential, we can make the system easier to use for everyone. How do we create a set of reusable colors that are memorable and easy to use?

As you might have gathered in the previous section, I’m a big proponent of implementing colors with semantic names, which clarifies usage and makes maintenance easier. Not to mention, it makes dashboard color schemes more feasible, especially for dark mode.

Here’s an example set of variables we could use:

--color-primary
--color-error
--color-warning
--color-success
--color-background: light gray background used in WordPress.
--color-surface: white background used for UI elements.
--color-border: border color used on UI elements.
--color-on-surface: default dark gray text/icon color.
--color-on-surface-subtle: light gray text/icon color.

These are just suggestions, and we’ll need to propose this in the correct channels to developers.

Next steps and feedback

Actionable next steps:

  • Start writing documentation for how to use the colors (draft started).
  • Open a PR in the Gutenberg repo to add the new colors (PR draft started).
  • Publish Figma colors styles (added to Proposals page).
  • Discuss (in the right channels) how to implement colors in code.

I’m open to feedback on the actual colors themselves as well as suggestions for implementation. I’ve been using this color system with several projects and it seems to be working well. What do you think?


Further reading:

#colors, #style-guide