How to Turn Brand Colors Into an Accessible Website Palette

A logo might use one vivid blue, one warm accent, and white. A website needs far more decisions: body text, muted text, page backgrounds, cards, borders, links, buttons, focus rings, selected states, success and error messages, charts, and dark mode. Copying the three logo swatches into every interface role does not create a coherent or accessible system.

Start with the identity colors, then build a semantic palette whose pairs have known jobs and tested contrast. The brand stays recognizable through disciplined use of its strongest colors—not by forcing the primary swatch behind every sentence.

Understand what the logo exception does not cover

WCAG's text-contrast criterion exempts text that is part of a logo or brand name. This keeps a required identity color from making the logo itself nonconforming. The exception does not apply to ordinary headings, button labels, navigation, pricing, form help, or a tagline used as page content.

Likewise, essential brand graphics may have a non-text contrast exception, but interactive controls and meaningful interface indicators still need to be perceivable. A pale logo may remain pale; a pale outline around an input cannot become invisible merely because it uses the same brand color.

Treat the logo as artwork and the product UI as communication. They can share a visual language without sharing every exact color pair.

Begin with roles, not a shade generator

Before making ten lighter and darker versions of the primary swatch, list the roles the interface needs:

• Canvas, elevated surface, and subtle surface.
• Primary, secondary, and muted text.
• Default, hover, active, visited, and focus link states.
• Primary and secondary buttons in every interaction state.
• Input border, focus ring, placeholder, error, and disabled treatment.
• Success, warning, danger, and informational messages.
• Dividers, icons, selected rows, charts, and data labels.
• Equivalent dark-mode roles.

This inventory prevents a common failure: a visually pleasing scale with no documented pairings. A hex code is not accessible in isolation. Contrast depends on the foreground, background, text size, weight, and function.

Build approved foreground and background pairs

For WCAG 2.2 Level AA, normal text needs a contrast ratio of at least 4.5:1 against its background. Large text—at least 18 point regular or 14 point bold, approximately 24 and 18.5 CSS pixels—needs at least 3:1. Do not round a near miss up; 4.49:1 is below a 4.5:1 threshold.

Meaningful graphical objects and the visual information needed to identify interface components generally need 3:1 against adjacent colors. This affects focus rings, selected-state indicators, standalone icons, chart lines, and control boundaries when those visuals are necessary to understand the component.

Create a pairing sheet rather than a swatch sheet:

Use your actual color values and record the computed ratio beside each approved pair. This gives designers and developers a bounded system instead of asking them to run a contrast checker for every new component.

Preserve the brand without using the brightest color for text

A vivid mid-tone brand color may work beautifully in the logo and fail as small text on white. Keep it for large decorative fields, illustrations, selected fills, or the mark itself. Create a darker companion for links and text, then connect the two through shape, typography, and repeated use.

For example, a bright cyan can remain the recognizable accent while a deep teal carries readable link text. This is not abandoning the brand; it is giving the brand a functional tonal range. Define the relationship in the guidelines so teams do not independently invent darker approximations.

White text on a bright brand background is another frequent failure. Darken the fill, use dark text, increase the component size only if the text truly qualifies as large, or reserve the bright color for an outline or accent. Do not add a text shadow and assume the whole label now passes; contrast must be evaluated against the colors immediately around the glyphs.

Do not rely on color alone

Red and green status colors can have adequate luminance contrast and still be ambiguous to someone who does not distinguish their hues. Add words, icons, patterns, or position. An error field should include an error message and a programmatically associated state, not just a red border.

Links inside prose should use an underline or another non-color cue, especially when the link color is close to surrounding text. Charts need direct labels, shapes, line styles, or patterns when color carries category meaning. Hover is not an adequate second cue for touch or keyboard users.

Treat dark mode as a new set of pairs

Do not invert light-mode hex values mechanically. Saturated colors can vibrate against near-black surfaces, shadows behave differently, and a disabled state that was subtle on white can vanish entirely. Define semantic dark tokens, then test each component state again.

Dark mode often needs lighter text colors and slightly muted accents, but avoid pure white for every hierarchy level. Use tested near-white and gray roles to preserve hierarchy. Check the logo separately: a dark wordmark may need an approved reversed variant rather than a CSS filter that changes all brand colors unpredictably.

Ship tokens with guardrails

Name tokens by purpose—text-primary, surface-raised, action-primary, focus-ring, status-danger-text—rather than exposing only blue-6 and gray-8. Primitive scales are useful under the hood, but semantic aliases tell a product team which values can be paired.

Document contrast ratios, usage, prohibited pairings, and state examples in the brand kit. Then test real rendered pages at normal zoom, with keyboard focus, forced zoom, and representative display conditions. An accessible palette is not a new set of colors competing with the identity. It is the operating system that lets the identity communicate clearly.