Creating Color Contrast Guidelines to Meet WCAG 2.1 and Beyond

Image of abstract painting, with horizontal swaths of moody blues and blacks and white highlights. Resembles ocean waves at dusk.

Photo by Henrik Dønnestad on Unsplash

At Salesforce, we want to ensure all our experiences meet or exceed current WCAG (Web Content Accessibility Guidelines) standards. These accessibility guidelines, while comprehensive, can be overwhelming to absorb. They’re also open to interpretation. A group of engineers and designers across our accessibility and design systems teams partnered to evaluate the latest WCAG color contrast guidelines and streamline standards for our work. We wanted to fully integrate WCAG and hope our process can inspire your teams to do the same.

We built on the work we did in 2020 to create and launch a new color system. The color system uses numerical values, which gives users a quick way to know what the color contrast ratios are. It complements other tools like WebAim: Contrast Checker or plugins. Using our color model as our foundation, our team started to craft color contrast guidelines for our design system with the goal of incorporating current and expected updates to future-proof our practices

Our approach

First, we needed to align on target definitions. What does it mean to meet a WCAG guideline? We assessed each level and created a target definition.

Various Levels of Contrast (Text and Non-Text)

Next, we evaluated all the patterns in our Lightning Design System for common and repeatable visual usage that had color-conveying meaning. For example, we grouped radio buttons, checkboxes, text inputs, sliders, etc., into “Inputs.” This audit helped us isolate similar use cases within each component category.

A 2-by-4 table listing inputs and state with adjacent colors and background.

We also worked to define terms and key concepts to establish the meaning of “visual.” After identifying the elements we use to compose a visual language for an interactive user experience, we were able to define categories for our UI.

Terms of Identification

The following are terms we use to describe elements within a UI.

Functional: A visual in the UI that’s required for interaction, is informational, or aids in error prevention.

A blue button containing the word “button” in white.

Functional

In this example, a button, the text, and the background are required to be color contrast compliant because it’s an interaction element.

Decorative: A visual in the UI that doesn’t convey information or function (e.g. an illustration or a redundant object).

Illustration of Astro laying on its belly next to a bowl of popcorn.

Decorative

In this example, the illustration of Astro is being used to express Salesforce’s brand. It doesn’t include information or functionality that would disrupt a user from making progress. Because of that, the illustration isn’t required to pass color contrast and would be hidden from assistive technology.

Redundant: A visual element becomes redundant when paired with a functional element.

Image of a progress bar, with a blue bar on the left and gray on the right. The phrase “50% complete” is above the gray bar on the right.

Redundant progress bar

In the progress bar example, the descriptive text “50% Complete” makes the blue and gray progress graphic redundant.

Image of a list of links and icons.

Redundant icons

Under “Related List Quick Links,” pairing descriptive text and an icon makes the icons redundant.

Redundant vs Informational

What’s the difference between something that’s redundant and something informational?

Image of a progress bar, with a blue bar on the left and gray on the right. The phrase “50% complete” is above the gray bar on the right.

Redundant

In the first progress bar, the descriptive text “50% Complete” makes the blue and gray graphic of progress redundant.

Image of a progress bar, with a blue bar on the left and gray on the right.

Informational

If we remove the descriptive text, the blue and gray graphic of progress would become informational.

Contextual Awareness: Recognizing that a pattern may live in multiple places.

Just because an element is compliant in one part of an experience doesn’t mean that it’s compliant elsewhere.

Image of a drop-down box containing an icon on the left and the text “search accounts.”

Example 1

In the first example, the icon isn’t paired with descriptive text, so it’s required to meet a 3:1 contrast ratio or greater.

Image of a dropdown box with two icons paired with descriptive text.

Example 2

In the second example, the icon is paired with descriptive text so it isn’t required to meet a 3:1 contrast ratio.

Color Contrast Rules

After the component audit and receiving feedback, we found that it was easiest to group UI into two categories based on color contrast parameters. They are non-text objects (like an icon) and text objects (anything with text). This presented our team with an opportunity to further simplify holistic guidance.

What needs to be 4.5:1 contrast ratio or greater?

A square graphic, with the top half demonstrating good contrast with white type on a blue background and the bottom half demonstrating bad contrast with a pale color and white type.

Our initial component audit identified color contrast relationships within each component. When reviewing WCAG guidance, it was easy to find and document the following bulleted rules for what needs to be 4.5:1 contrast or greater.

Non-bold text that’s less than 24px (1.5rem, 18pt) must meet 4.5:1 contrast.
Bold text that’s less than 19px (~1.2rem, 14pt) must meet 4.5:1 contrast

For bold text, we approximated guidance by rounding up within the WCAG guidance of between 18px and 19px. Next, we moved on to what needs to meet 3:1 contrast or greater.

What needs to be 3:1 contrast ratio or greater?

Text that is larger than 24px is considered “large” and can be as low as 3:1 contrast.
Iconography (unless decorative).
Objects that are functional and can be interacted with. This includes any visible boundary.

A square graphic, with the top half demonstrating good contrast with blue type on a light background and the bottom half demonstrating bad contrast with blue type on a blue background.

We applied the same process from text objects to non-text objects and used our terms of identification to make objective rules. For example, redundant iconography technically wouldn’t need to pass contrast. Leaning on an abstract application of contextual awareness, there might be other scenarios where an icon lives and isn’t redundant. We decided it was simplest for us to declare all icons to meet a 3:1 color contrast or greater.

Note: This is an area of guidance where we decided to make a global rule for icons even though it technically doesn’t need to pass in all scenarios. If you choose to create your own guidelines, this is an example of where you can go beyond WCAG bare minimums.

Framework

As we moved through this process, we continued to recognize areas where we could simplify. We started with a widespread audit that identified color contrast needs within a single component to create terms and apply them to the creation of high-level, highly consumable, color contrast guidance for our design culture.

“If something is designed to be seen, make it be seen” — Jory Cunningham

Learning from one another during this process promoted conversations of shared learnings. For example, conversations about icons had us discussing why something designed to be seen doesn’t need to meet contrast in one place but does in another. This led us to create a unifying statement for the UI for our visual language: If the design elements with any design pattern contain information critical to understanding the interaction, it will need to pass color contrast.

Color Contrast Rules

If it serves a function, make it contrast compliant. Intended visibility must pass contrast.

Color contrast applies to text, state indicators, purpose indicators, and anything else that can be interpreted as crucial to understanding an interaction.
If a primary function is visible at all, it should be visible for all unless it’s purely decorative.

2. Text always requires contrast

Text contrast requires 4.5:1 unless it’s very large; everything else is 3:1.

3. Don’t rely only on color to convey meaning, use secondary information sources

Avoid using color as the sole indicator of state in a component. Color should never be a primary indicator for something that’s functional.
When trying to avoid relying on color for communication, height/width changes, icons, and secondary text-based indicators are your friend.

Lessons

WCAG guidelines state the minimum requirements, but we wanted our guidelines to exceed the standards. There are always opportunities to make experiences more accessible. Here’s what we learned:

Coming together and having honest conversations was critical to our success. Across each of our disciplines, we had our own interpretations and areas of learning. Communicating early and often kept us moving forward together.
When we shared our respective experiences related to color contrast guidance, we uncovered some contradictions. We used that as an opportunity to align and create an informed position to support our ecosystem of products and digital experiences.
Accessibility can often be an afterthought in the product development or design cycle. When your design team has clear guidelines, they will be empowered to make visual language decisions that deliver a more accessible experience. Going beyond current guidelines now minimizes disruptive updates later.

The Salesforce color guidelines we created for our design system are a strong first step in making Salesforce experiences color contrast compliant. We are now applying these rules to our patterns. Expect updates soon!

Thank you to the members of our color contrast workgroup Jesse Hausler and Jory Cunningham from our accessibility team and Kim Flournoy from our design systems engineering team. Shout out to Hsiao-Ching Chou and Alan Weibel for their support too!

Salesforce Design is dedicated to elevating design and advocating for its power to create trusted relationships with users, customers, partners, and the community. We share knowledge and best practices that build social and business value. We call this next evolution of design Relationship Design. Join our Design Trailblazers community, become a certified UX designer, or work with us!