Design System Team/Color/Design documentation

The Codex design system color palette is used to bring visual meaning or accent to interface elements and convey specific messages in certain instances. The palette has seen multiple iterations over time, as it expanded to meet new needs of the design system. As the system continues to grow, we find ourselves at another point of expansion at the time of writing this entry. This page is meant to serve as a place to document design goals, learnings, and thought processes in the journey of expanding the Codex color palette.

Note: this documentation refers to Codex and not the Wikimedia Foundation brand colors.

Why more colors?

Most recently, Codex added more colors to the previous palette to support the addition of dark mode. The colors added were meant to serve only the purpose of supporting dark mode, and fitting into the numerical value structure that had already existed (100 being the lowest value of any color and 800 being the highest). The specific values of the colors that were added were derived directly from the existing palette and from other Wiki environments here Codex wasn't being used.

We knew this process was not perfect, and would benefit from follow-up task of further expanding the color palette, while cleaning up the numerical value structure to make things more consistent and cohesive, meaning visually aligning each value of every color in a saturation and luminance sense.

Expansion goals

1. At the foundational, style guide color level, create a more complete set of colors, spanning a larger range of the color spectrum, with equivalent values for each color. For example, every color (gray, red, blue, green, etc.) all have values ranging from 50 to 1000.
2. At the application level, maintain at least WCAG 2.2 Level AA color contrast, and improve visual accessibility where possible.
3. Limit the amount of prominent visual changes. For example, reduce changes to colors like the gray palette and the main progressive blue.

Writing guidance

From a guidance perspective, with this color expansion, we can provide the community with guidance on what colors can be used when and with what other colors, as well as consider more holistic guidance for things like data visualization.

Accessibility and APCA

The current WCAG version 2.2 at this iteration of the color expansion measures the differences between colors using perceived luminance, commonly referred to as "simple color contrast". An example of this can be found here.

ACPA, or Advanced Perceptual Contrast Algorithm, takes into consideration font weight and size, color (or perceived lightness differences between two colors), and context (visual surroundings and intended purposes of text) to measure the visual accessibility of color. Though we have this current understanding of this form of color measurement in the future next version of WCAG 3, there is not enough information to influence a major affect on the current color expansion. Therefore, the way application colors will be applied at this point will continue to be based off of WCAG 2 standards and criteria.

Considering dark mode

When adding new color values which will commonly be used in dark mode, i.e. the lighter values, we want to be careful that these colors find a balance between conveying the hue they are meant to without being too saturated or bright. This will help readability in dark mode as the brighter, more saturated colors can cause eye strain. The same reasoning applies to what color we assign to application tokens used for text, primarily in the gray palette. We want to avoid using the lightest gray, and especially white, for primary uses of text in dark mode.

Changing existing color values

The expansion will not only include adding new colors, but changing existing colors. This is to ensure we can have a palette that creates consistent perceived lightness, brightness, and saturation across colors of similar values. In changing existing values, we will start from any existing, primary value and adjust until we find the right balance across all colors and values. Choosing colors cannot happen at a micro level but at a macro one, to ensure the palette as a whole is cohesive. This also helps us make blanket accessibility statements in both light and dark modes, such as:

• In light mode, the darkest that a background can be is the 100 value of Gray, and the 50 value of all other colors. Then, the lightest any text can be on that those backgrounds is the 600 value of Gray, and the 700 value of all other colors. Additionally, the lightest any graphical element can be is the 500 value of Gray, and the 600 value of all other colors.
• In dark mode, the lightest that a background can be is the 800 value of Gray, and the 900 value of all other colors. Then, the darkest any text can be on that those backgrounds is the 400 value of all colors. Additionally, the darkest any graphical element can be is the 500 value of all colors.

Naming new colors

There are a few new colors we will be adding into the Codex palette, to help achieve the first goal and support more broader color palette needs. These colors include Orange, Lime, and Pink. When naming new colors, we want to consider ease of spelling and familiarity, as well as existing naming conventions.

Orange and Pink are entirely new colors, spectrum-wise. When naming Lime, we could consider using the name "Green" instead, and renaming the existing green color. However, this introduces more complexity and confusion than necessary. So we are moving forward with the name Lime.

Other considerations

Color organization

With the addition of more colors, we are considering how the entire set of colors should be organized and if we can order them more logically. The approach we are moving forward with is based on the visual color spectrum, starting with Red and ending with Maroon. The organization of these colors in this way occurs in Figma, code, and the Codex docs site.

Sepia mode

Soon, we will need to consider a more warmly toned gray palette to support Sepia mode not only in its current existence within mobile apps, as the apps begin to use Codex, but also the potential of a Sepia mode on web. We will need to consider the name of this color. Currently, there are uses of a "Taupe" and "Beige" in the mobile apps color system. One problem with both of these names is that they can be difficult to spell. We could name this color "Sepia". While that is the name of the mode, it is also the name of the color. While it might also be slightly difficult to spell, the familiarity of the mode name could be a reason that we move forward with this name.

Disabled elements

Within the realignment of certain elements of the Gray palette and how those colors are applied in context, we could consider a more distinctive jump from the tokens `disabled` and `disabled-subtle`. Part of the overall proposal changes the jump between these two tokens from two values different, i.e. 300 and 200 (with a currently 250 sitting between those two), to one value different. This would result in the disabled state for input type components to be slightly darker. We should consider the importance of disabled visual styles, and if it feels more important to not make disabled elements feel too prominent (the darker background color does do this slightly) or to widen the difference between a disabled element and an enabled element (the darker background color does this more prominently).