Color Accessibility (WCAG 2.1)

Color contrast is the single accessibility requirement designers encounter most. Get it right and you ship inclusive interfaces; get it wrong and a non-trivial fraction of users cannot read your product.

WCAG 2.1 contrast — the numbers you need

• SC 1.4.3 Contrast (Minimum) — AA
  • Normal text: 4.5:1 against background
  • Large text (18pt regular or 14pt bold+): 3:1
• SC 1.4.6 Contrast (Enhanced) — AAA
  • Normal text: 7:1
  • Large text: 4.5:1
• SC 1.4.11 Non-text Contrast — AA — UI components, meaningful icons, focus rings: 3:1.

How contrast is calculated

For each color, compute relative luminance (a weighted linear-RGB sum using sRGB gamma). The ratio is (L_lighter + 0.05) / (L_darker + 0.05). Ratios go from 1:1 (same color) to 21:1 (pure white on pure black).

Use our contrast checker or check any color from our color directory— every page reports AA/AAA results for normal and large text.

Where APCA fits

APCA (Accessible Perceptual Contrast Algorithm) is useful because it models perceived lightness contrast more realistically than the WCAG 2 ratio, especially for dark themes, very bold type, and low-luminance UI. It is not a replacement pass/fail gate for WCAG 2.1 today. Treat it as a second review signal: WCAG AA answers "can this ship under the current standard?", while APCA helps answer "will this actually feel readable in the UI context?".

• Use WCAG AA as the minimum compliance gate for body text and controls.
• Use APCA to compare candidate pairs that all technically pass WCAG.
• Recheck APCA when changing font weight, size, background elevation, or dark-mode surface.
• Do not let an APCA-friendly pair override a WCAG failure without an accessibility review decision.

Accessibility workflow for brand colors

Brand color accessibility works best as a release workflow, not an after-the-fact audit. Each brand color should ship with approved text pairings, UI-only limits, and a documented failure path for combinations that look on-brand but fail contrast.

• Classify the color: background, text, border, icon, focus ring, chart, status, or decorative.
• Test intended pairs: run the actual foreground and background through the contrast checker, not a nearby palette approximation.
• Record approved usage: normal text, large text, non-text UI, decorative only, or rejected.
• Attach a fallback: if brand red fails on white for small text, define the darker accessible red or use the red only as an accent with black body text.
• Review color-blind states: confirm status colors remain distinguishable with icons, text labels, or shape.

Patterns that work

1. Lock in a contrast-safe text color from the start

Pick a single dark text color and a single light text color at the beginning of a project. Verify each backgrounds you use those on hit 4.5:1 minimum. Avoid mid-tones for body text.

2. Don't rely on color alone

SC 1.4.1 — never use color as the only carrier of meaning. Pair red with an X icon, green with a check, blue links with underlines. ~8% of men have some form of color vision deficiency; relying on hue alone excludes them.

3. Test against simulated color blindness

Use a color blindness simulator (we have one in tools) to view your interface in protanopia, deuteranopia, and tritanopia. If anything becomes unreadable, the design needs another signifier.

4. Focus states above 3:1

Focus rings must be visible. A 3:1 contrast against the focused component's background is the minimum. Brand-blue focus rings on light gray inputs often fail this — verify with your color picker.

5. Pair text contrast with size

Large text gets a lower threshold (3:1) because it is more legible at lower contrast. If your design system has a "small" 12px gray secondary text, it needs to clear 4.5:1 — and probably should not exist as a permanent style.

Design-system acceptance criteria

The fastest way to keep color accessible is to put acceptance criteria directly into the design-token review. A token should not be marked "ready for production" until the team knows where it can and cannot be used.

• Text tokens list at least one approved surface pairing at AA normal size.
• Surface tokens list approved foreground text and icon colors.
• Border and focus tokens clear 3:1 against adjacent surfaces.
• Status tokens include a non-color signifier: text, icon, shape, or pattern.
• Dark-mode values are tested independently; passing in light mode does not imply passing in dark mode.
• Token documentation records WCAG result, APCA review note, intended text size, and allowed component contexts.

Example: fixing an inaccessible brand button

Suppose a brand uses a vivid yellow button with white text. It may look energetic in a marketing deck but fail WCAG for product UI. The production fix is not "make everything darker" by instinct. Test three options:

• Keep the yellow background and switch the label to black text.
• Use a darker shade of the brand yellow for interactive controls.
• Keep yellow as an accent and use a neutral high-contrast button for primary actions.

The approved decision should be recorded in Figma Variables and code tokens so the inaccessible pair does not reappear in a future feature.

Tools and audits

• Design-time: Figma plugins (Stark, Able), our contrast checker.
• Code-time: ESLint plugin eslint-plugin-jsx-a11y, axe-core in tests.
• Runtime: Chrome DevTools Lighthouse, axe browser extension, screen reader QA pass.
• Org-level: regular accessibility audits, user research with assistive-tech users.

The bottom line

Accessible color is not extra polish — it is a baseline requirement. Build the math into your design system so every brand color comes with its safe-pair partners pre-validated, and you'll never ship an inaccessible interface by accident.