How Designers and Engineers Can Standardize Color Names | Color Management for Web Development

During web development, a designer may say “dark blue,” an engineer may call the same color “primary,” and a content manager may refer to it as “the sign-up button color.” All three may think they mean the same thing, yet misunderstand each other when the design changes. To standardize color names, agree not only on how a color looks but also on where and why it is used. A sign-up form provides a practical example.

Use shared role names rather than just “blue” or “dark blue”

Labels such as “blue 1” or “light blue” quickly become confusing if a redesign changes their shades. Start with roles such as “page background,” “body text,” “primary button background,” “primary button text,” “input border,” and “error text.” These names identify what each color does in the interface, even if its actual shade changes.

Role-based names can be managed as color tokens: shared labels that refer to specific color values. In CSS (Cascading Style Sheets, the language used to style web pages), a custom property can use a name such as --color-action-primary-bg. In this example, “primary” identifies the main sign-up action; it does not mean every blue color on the site.

Map the descriptive name used in design documents to one implementation name. Choose labels that remain accurate if the shade changes, and do not use “main,” “primary,” and “brand” interchangeably for a single role. Conversely, a decorative brand color and an error indicator should have separate roles even if they happen to look similar.

Create a shared color-name table for a sign-up form

For a sign-up form, designers and engineers can use the following mapping in both design documents and code. A HEX color code specifies a web color using a “#” followed by six hexadecimal digits. Each row includes a role, its implementation name, a color swatch, and its usage.

In this example, body text against the page background has a contrast ratio of approximately 14.03:1, white text against the blue primary button has approximately 6.70:1, and error text against the white input background has approximately 6.57:1. The input border against its white background has approximately 4.76:1. A contrast ratio measures the difference in relative lightness. Matching the names is useful, but you still need to check the actual neighboring color values.

When someone requests a “slightly darker button,” naming the specific role “primary button background” helps avoid accidental changes to body links or decorative brand elements. The key is for design documentation and CSS to refer to the same role.

Agree on a review process for additions and renames

Maintain one shared record of each role name, CSS name, color code, screen where it is used, neighboring foreground or background, reason for the change, and reviewer. Before creating a new name, check whether an existing role can be reused. Add a new one only when it serves a different purpose. When retiring an old name, have the designer and engineer review the affected screens before switching references.

After changing a color, check more than the button’s default appearance. Inspect hover (when a pointer rests over a control), keyboard focus indicators, and error states. If the colors differ across states, give those state-specific colors their own names. A common naming system does not automatically make the resulting interface accessible.

Under WCAG (Web Content Accessibility Guidelines) Level AA, normal-sized text generally needs a contrast ratio of at least 4.5:1 against its background, while large text needs at least 3:1. The visual information needed to identify control boundaries or meaningful icons generally needs at least 3:1 against adjacent colors. Even after the names are agreed upon, verify the real color combinations on each screen and in each interaction state.