Color contrast and WCAG standard in branding
Is it true that brand colors are exempt from WCAG requirements
No, and this is one of the most persistent misconceptions in branding. The text of the standard explicitly states: «Corporate visual guidelines beyond logo and logotype are not included in the exception» — that is, the exception applies only to the logo and logotype as graphical identity objects. Everything else: corporate buttons, text blocks, icons, infographics in the brand book — must comply with the same contrast thresholds as any other interface element.
The logic is simple: a logo is a recognizable graphic symbol, its form and color carry meaning by themselves, and demanding that it meet contrast requirements would be equivalent to demanding that the coat of arms be repainted. A button labeled «Buy» does not carry semantic meaning through its shape — its function is only readable through the text, and if the text is unreadable, the function does not work regardless of how «on-brand» the color is.
Why is contrast calculated through lightness rather than hue
WCAG formula works with relative luminance — a value that shows how much light a color "reflects" when converted to grayscale tones. Hue does not participate in this formula at all: red, green, and blue colors with equal luminance will produce the same contrast against the same background.
This is fundamentally important for design systems: choosing pairs of 'text color — background color' must not be based on whether the shades visually 'match,' but on the difference in their brightness. That is why in modern design systems, colors are described not only through HEX, but also through a brightness scale (lightness in HSL or OKLCH) — this makes it easier at the palette creation stage to immediately see which combinations can theoretically pass the threshold and which cannot.
Case: how to bring a brand color to a working state without losing its identity
Let's take the same #fd109a — a saturated pink that the brand chose as its main accent color. The task is to use it for text, buttons, and to pass AA. A direct solution like 'make the text slightly darker' breaks the identity if done by eye. A role-scoped approach works — where each color has a clearly defined role, rather than one value for all cases.
- The pink remains the main accent (
--signal), but is only used where the contrast is objectively sufficient: large headings, illustrative elements, fills of large buttons — where the 3:1 threshold is easily achieved. - A separate token is created for text on a pink background
--signal-ink— usually this is white or very dark, almost black color, chosen specifically for contrast with--signal, not the 'standard black from the brand book'. - For regular text, the brand uses not the pink itself, but its darker variant or the basic neutral
--ink— the pink in this role simply cannot physically pass AA at a reasonable saturation. - Gray text (captions, secondary information) is bounded below: Gray-500 (#737373) on white yields 4.6:1 — this is the critical threshold, the lightest gray that still passes AA. Anything lighter no longer qualifies for body text, no matter how neatly it appears in the layout.
In summary: the brand does not 'ruin' its pink color, but rather distributes roles — the vivid color is used where its brightness does not interfere with readability, and where text is needed, a pre-prepared contrasting pair is activated. This is the systemic approach instead of manually adjusting colors in each individual layout.
Color vision deficiency and contrast: why luminance calculation works independently of vision type
Deuteranopia (color vision deficiency for green) occurs in 1–5% of men, protanopia (color vision deficiency for red) — in 1% of men. For this audience, the classic pair of 'green button — red error text,' which relies on subtle differences in hue, may visually merge into an almost indistinguishable spot.
Calculating contrast based on relative brightness works in favor of this audience by default: if two colors differ in lightness sufficiently, the difference will still be readable even with complete loss of the color channel. Therefore, in branding, it is a bad idea to encode meaning only through hue (green = success, red = error) without difference in lightness or without additional visual markers (icon, shape, label). Contrast checking according to WCAG partially addresses this issue automatically, but not fully — it guarantees text readability, but not that two status colors won't be confused with each other.
Requirement 1.4.11: contrast is not only for text
A separate WCAG criterion — 1.4.11 Non-text Contrast — concerns graphical interface elements that carry functional meaning. The threshold here is lower than for text, but the requirement is no less mandatory: 3:1 against adjacent colors.
- Icons that convey information or serve as control elements (not decorative)
- Borders of form fields, checkboxes, and toggles
- Focus indicators — a border or background when navigating via Tab
- Lines and segments in charts, graphs, and infographics
- Borders of cards and buttons, if the border itself defines their shape against the background
This is exactly the area that brand guides usually overlook: while the brandbook specifies the text color and background color, no one checks whether the input border is visible on a light gray background or whether the contour of an action icon is distinguishable on a product card.
How to build a design system palette, not manually adjust colors
The systemic flaw of most brands is testing contrast post-factum, when the palette has already been approved and accepted. The correct order is the reverse: first, token roles are established, then specific color values are selected to match them.
| Token | Role | Contrast requirement |
|---|---|---|
| --signal | main brand color, accents, large fills | 3:1 to background (for large elements) |
| --signal-ink | text/icons on fill --signal | 4.5:1 to --signal |
| --ink | main text on surface | 4.5:1 k --surface (7:1 for AAA) |
| --surface | background of cards, pages, modals | base for calculating all other pairs |
| --border | borders, dividers, field contours | 3:1 k --surface (1.4.11) |
This approach eliminates the question of 'which brand shade to choose for text' at the system architecture level — the designer does not choose the color every time anew, but selects a role, and the token already reliably passes the required threshold. AA level (4.5:1 for text, compensates for vision level 20/40 — typical for people around 80 years old) is sufficient for most commercial products. AAA level (7:1, vision compensation 20/80) should be built into medical, government, and educational services, where among users there is inevitably a high proportion of people with significant vision impairment — and there the strict contrast is more important than the visual softness of the brand.
The logic is simple: a logo is a recognizable graphic symbol, its form and color carry meaning by themselves, and demanding that it meet contrast requirements would be equivalent to demanding that the coat of arms be repainted. A button labeled «Buy» does not carry semantic meaning through its shape — its function is only readable through the text, and if the text is unreadable, the function does not work regardless of how «on-brand» the color is.
Why is contrast calculated through lightness rather than hue
WCAG formula works with relative luminance — a value that shows how much light a color "reflects" when converted to grayscale tones. Hue does not participate in this formula at all: red, green, and blue colors with equal luminance will produce the same contrast against the same background.
This is fundamentally important for design systems: choosing pairs of 'text color — background color' must not be based on whether the shades visually 'match,' but on the difference in their brightness. That is why in modern design systems, colors are described not only through HEX, but also through a brightness scale (lightness in HSL or OKLCH) — this makes it easier at the palette creation stage to immediately see which combinations can theoretically pass the threshold and which cannot.
Case: how to bring a brand color to a working state without losing its identity
Let's take the same #fd109a — a saturated pink that the brand chose as its main accent color. The task is to use it for text, buttons, and to pass AA. A direct solution like 'make the text slightly darker' breaks the identity if done by eye. A role-scoped approach works — where each color has a clearly defined role, rather than one value for all cases.
- The pink remains the main accent (
--signal), but is only used where the contrast is objectively sufficient: large headings, illustrative elements, fills of large buttons — where the 3:1 threshold is easily achieved. - A separate token is created for text on a pink background
--signal-ink— usually this is white or very dark, almost black color, chosen specifically for contrast with--signal, not the 'standard black from the brand book'. - For regular text, the brand uses not the pink itself, but its darker variant or the basic neutral
--ink— the pink in this role simply cannot physically pass AA at a reasonable saturation. - Gray text (captions, secondary information) is bounded below: Gray-500 (#737373) on white yields 4.6:1 — this is the critical threshold, the lightest gray that still passes AA. Anything lighter no longer qualifies for body text, no matter how neatly it appears in the layout.
In summary: the brand does not 'ruin' its pink color, but rather distributes roles — the vivid color is used where its brightness does not interfere with readability, and where text is needed, a pre-prepared contrasting pair is activated. This is the systemic approach instead of manually adjusting colors in each individual layout.
Color vision deficiency and contrast: why luminance calculation works independently of vision type
Deuteranopia (color vision deficiency for green) occurs in 1–5% of men, protanopia (color vision deficiency for red) — in 1% of men. For this audience, the classic pair of 'green button — red error text,' which relies on subtle differences in hue, may visually merge into an almost indistinguishable spot.
Calculating contrast based on relative brightness works in favor of this audience by default: if two colors differ in lightness sufficiently, the difference will still be readable even with complete loss of the color channel. Therefore, in branding, it is a bad idea to encode meaning only through hue (green = success, red = error) without difference in lightness or without additional visual markers (icon, shape, label). Contrast checking according to WCAG partially addresses this issue automatically, but not fully — it guarantees text readability, but not that two status colors won't be confused with each other.
Requirement 1.4.11: contrast is not only for text
A separate WCAG criterion — 1.4.11 Non-text Contrast — concerns graphical interface elements that carry functional meaning. The threshold here is lower than for text, but the requirement is no less mandatory: 3:1 against adjacent colors.
- Icons that convey information or serve as control elements (not decorative)
- Borders of form fields, checkboxes, and toggles
- Focus indicators — a border or background when navigating via Tab
- Lines and segments in charts, graphs, and infographics
- Borders of cards and buttons, if the border itself defines their shape against the background
This is exactly the area that brand guides usually overlook: while the brandbook specifies the text color and background color, no one checks whether the input border is visible on a light gray background or whether the contour of an action icon is distinguishable on a product card.
How to build a design system palette, not manually adjust colors
The systemic flaw of most brands is testing contrast post-factum, when the palette has already been approved and accepted. The correct order is the reverse: first, token roles are established, then specific color values are selected to match them.
| Token | Role | Contrast requirement |
|---|---|---|
| --signal | main brand color, accents, large fills | 3:1 to background (for large elements) |
| --signal-ink | text/icons on fill --signal | 4.5:1 to --signal |
| --ink | main text on surface | 4.5:1 k --surface (7:1 for AAA) |
| --surface | background of cards, pages, modals | base for calculating all other pairs |
| --border | borders, dividers, field contours | 3:1 k --surface (1.4.11) |
This approach eliminates the question of 'which brand shade to choose for text' at the system architecture level — the designer does not choose the color every time anew, but selects a role, and the token already reliably passes the required threshold. AA level (4.5:1 for text, compensates for vision level 20/40 — typical for people around 80 years old) is sufficient for most commercial products. AAA level (7:1, vision compensation 20/80) should be built into medical, government, and educational services, where among users there is inevitably a high proportion of people with significant vision impairment — and there the strict contrast is more important than the visual softness of the brand.
Recent articles
MegaFon, BMW, VTB and more 240+ companies. See how it looks in the showcase reel:
Our branding agency is approached to order:
Branding agency services
