Build an accessible color system by defining semantic roles and testing actual foreground-background pairs against applicable WCAG 2.2 criteria. Criterion 1.4.3 covers minimum text contrast, criterion 1.4.11 covers certain non-text visual information, and criterion 1.4.1 prohibits color as the only visual means of conveying information. Tokens and tools help consistency, but conformance depends on implementation and context.
Who this is for: Design-system teams defining reusable interface colors for text, controls, focus, status, charts, and themes.
- Model semantic roles and approved color pairs rather than handing teams an unrestricted palette.
- Evaluate text, controls, focus, states, charts, and themes against the WCAG criterion that applies.
- Pair color with text, shape, iconography, pattern, or position and verify implemented interfaces manually.
Start with roles and contexts
Inventory where color communicates: body text, links, disabled content, surfaces, borders, focus, selection, validation, status, charts, and overlays. Define semantic names such as text-primary or status-critical rather than names tied to hue. One raw color may work on one surface and fail on another.
Map states and themes as explicit pairs. Include hover, active, focus, selected, visited, disabled, and forced or high-contrast environments where relevant. Avoid treating disabled content as permission to make essential information unreadable. Document when an element is inactive and what alternative communicates its state.
Apply criterion-level contrast
WCAG 2.2 criterion 1.4.3 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for qualifying large-scale text at Level AA, with stated exceptions. Test rendered text against its actual background, including gradients, images, transparency, and state changes rather than checking isolated swatches.
Criterion 1.4.11 requires at least 3:1 contrast for visual information needed to identify user-interface components and states, and for parts of graphics needed to understand content, with exceptions. It does not mean every decorative border must meet that ratio. Determine which pixels carry necessary information in the actual component.
Do not rely on color alone
Criterion 1.4.1 requires another visual means when color conveys information, prompts a response, or distinguishes an element. Add visible text, an icon with a clear meaning, pattern, underline, shape, or positional label according to context. A legend made only of differently colored dots repeats the same dependency.
For charts, check adjacent series, labels, patterns, selection, and data access rather than only canvas contrast. For errors, connect text to the affected field and provide a message. For links within body text, review the applicable criterion and interaction cues instead of assuming brand color alone makes them identifiable.
Govern and verify implementation
Store approved semantic pairings, intended use, criteria considered, themes, and prohibited combinations. Automated checks can catch many contrast failures, but they cannot decide whether color carries meaning or whether a non-text boundary is necessary. Review components in realistic states, content, zoom, and platform rendering.
Test the built interface, not only design tokens or Figma frames. Product code may combine tokens incorrectly, add opacity, place text over media, or omit non-color cues. Include manual accessibility review and relevant user research. Record exceptions and remediation owners rather than claiming the color system guarantees conformance.
Define a hypothetical status palette
Hypothetical dashboard uses green, amber, and red dots as the only indication of service status.
- Define hypothetical semantic roles for normal, attention, and critical status on each approved surface.
- Test the actual text and necessary component boundaries against applicable WCAG 2.2 contrast criteria.
- Add visible status words and distinct icons so meaning does not depend on hue alone.
- Verify default, hover, selected, focused, dark-theme, zoomed, and implemented chart contexts manually.
Semantic color role record
Document approved use and evidence for each color relationship.
- Role, purpose, foreground token, background token, component, state, theme, and owner.
- Applicable WCAG criterion, measured pair, rendered context, text size or necessary graphic information, and result.
- Non-color cue, visible label, icon or pattern meaning, focus treatment, selection, and error association.
- Allowed combinations, prohibited uses, opacity rules, media overlays, chart guidance, and disabled behavior.
- Design review, implementation check, automated scan, manual verification, exception, and remediation date.
Common mistakes
- Checking raw palette swatches while ignoring the actual foreground, background, opacity, and interaction state.
- Using green and red alone for success and error without labels or another visible distinction.
- Claiming that accessible tokens guarantee WCAG conformance in every component and implementation.
Try one
A border has less than 3:1 contrast. Does WCAG 2.2 automatically require changing it?
A correct answer examines whether the border is necessary to identify a user-interface component or state under criterion 1.4.11. If spacing, fill, text, or another visual treatment already identifies the component, a decorative border may not carry required information. The team must evaluate the implemented context, keyboard focus, states, and other applicable criteria rather than applying one ratio mechanically.
Sources
- W3C WCAG 2.2 contrast criteriaCriterion-level references for text contrast and related visual presentation requirements.
- W3C WCAG 2.2 non-text contrast criterionCriterion 1.4.11 guidance for visual information needed to identify controls and states.
- W3C WCAG 2.2 use of color criterionCriterion 1.4.1 guidance against using color as the only visual means of conveying information.