Understanding the Contrast Thresholds
WCAG defines two levels of contrast ratio: AA and AAA. For normal text, which includes most body copy and labels, the minimum contrast ratio is 4.5:1 for AA and 7:1 for AAA. For large text, defined as at least 18pt regular or 14pt bold, the minimum is 3:1 for AA and 4.5:1 for AAA. Most brands fail accessibility checks because they apply a single contrast standard to all text sizes, ignoring the distinction between normal and large text. This leads to unnecessarily dark backgrounds or overly bright text, reducing visual hierarchy and brand personality.
The contrast ratio is calculated using relative luminance, not simple brightness. Relative luminance is a non-linear transformation of RGB values that approximates human perception of lightness. The formula for the contrast ratio between two colors, where L1 is the lighter color and L2 is the darker color, is (L1 + 0.05) / (L2 + 0.05). You cannot derive this ratio by averaging RGB channels or using simple grayscale conversion. If you are building a custom checker, you must implement the relative luminance calculation correctly, or rely on a tool that does.
Deriving Palettes from a Base Color
Starting with a single brand color is insufficient for a complete UI. You need a palette that includes primary, secondary, accent, and neutral tones, all of which must maintain acceptable contrast against their intended backgrounds. A common mistake is generating shades by simply darkening or lightening the base color in RGB space. This produces muddy, desaturated mid-tones that often fail contrast checks when used for text or icons. Instead, work in a perceptually uniform color space such as HSL or HSB, adjusting lightness and saturation while preserving hue. This yields cleaner, more predictable variations.
When deriving a palette, define your usage contexts first. Identify which colors will appear as text on light backgrounds, which as text on dark backgrounds, and which as interactive elements requiring focus states. Each context has different contrast requirements. A color that passes as a background may fail as text, and vice versa. Map your palette tokens to these contexts before finalizing any value. If a derived color fails its assigned context, adjust its lightness or saturation until it passes, rather than swapping it for an unrelated hue.
Testing Contrast in Practice
Do not rely on visual inspection to judge contrast. Human perception of contrast is inconsistent, especially for colors with similar luminance but different hues. Use a computational check for every text/background pair in your design system. When using a tool like ColorWell, you can input your base color and immediately see which derived tokens pass or fail WCAG AA and AAA thresholds for both normal and large text. This allows you to adjust the palette iteratively without leaving the design environment.
Exporting the validated palette to your codebase is critical for consistency. If your team uses CSS, Tailwind, or Figma, ensure the exported tokens match your internal naming conventions. Inconsistent token names lead to duplicated colors, ad-hoc overrides, and eventual drift from the accessibility-compliant set. Define your tokens once, export them in the format your stack requires, and treat them as immutable constants in your design system. Any deviation should go through a formal review process, not a quick edit in a component file.
Avoiding Common Pitfalls
One frequent error is assuming that a color that passes contrast on white will also pass on light gray or off-white backgrounds. It will not. Contrast ratios are relative to the specific background, not to a neutral reference. Always test against the actual surface color where the text will appear. Another pitfall is ignoring focus states. Interactive elements require visible focus indicators that meet contrast requirements against the element’s background. If your accent color fails contrast when used for a focus ring, you must choose a different indicator color or adjust the accent’s lightness.
Finally, do not treat accessibility as a final QA step. Contrast compliance is a design constraint, not a post-hoc fix. If you bake in a low-contrast brand color early, you will spend significant effort retrofitting exceptions, overrides, and special cases later. Integrate contrast checks into your palette derivation process from the start. Use tools that provide instant feedback during the design phase, such as ColorWell, to validate tokens before they enter your codebase. This keeps your system accessible by construction, not by exception.
Tool mentioned: ColorWell