How would you implement a high contrast mode theme in Figma?

What's really being asked

The interviewer wants to see if you understand that high contrast mode is a design-systems problem, not just a color-theming exercise. They are looking for knowledge of WCAG non-text contrast requirements, semantic token architecture, and how Figma variables and component properties scale across complex libraries. The question specifically probes whether you consider non-color assets like icons, photography, and focus states, which are where most token-only systems fail.

The full answer

First, token tier strategy. You should separate primitive color values from semantic tokens such as background-default or border-strong, then bind those semantic tokens to Figma variable modes so switching themes propagates without detaching instances. Second, icon and image handling. Pure color swaps break outlined icons or complex illustrations, so a robust system uses boolean component properties or variant swaps to toggle stroke weights, fill rules, or background containers for icons. For photography and imagery, you need treatments like persistent borders, reduced transparency, or masking rules because high contrast must not rely on color alone to distinguish elements. Third, focus indicators. WCAG 2.2 requires focus indicators to be visible and have sufficient size and contrast, so your Figma specs should define 2px minimum outlines with 3:1 contrast against adjacent colors, and you should document offset distances to prevent focus rings from being clipped by overflow masks. Fourth, governance and plugin workflows. Mention using Figma plugins for contrast auditing, documenting token decisions in your design system documentation, and aligning with engineering on CSS custom properties or theme objects so the Figma modes map one-to-one to code.

The mistakes people make

A major red flag is saying you would just duplicate the library and swap hex codes, which ignores maintainability. Another is forgetting that disabled states and placeholder text must also meet contrast minimums in high contrast mode, not just active UI. Candidates often miss focus indicators entirely or suggest adding shadows instead of solid outlines, which fails accessibility requirements. Treating icons as pure glyphs that inherit color without considering stroke inversion or background knockouts is also a common gap.

What usually comes next

The interviewer might ask how you would handle third-party icons or legacy assets that do not follow your token system. They may also ask how you validate contrast at scale across hundreds of components, or how you prioritize which components get high contrast treatment first. Another follow-up is how you would handle motion or animation in high contrast mode, since reduced motion preferences often overlap with accessibility theming.

A concrete example

Suppose your primary button uses a blue primitive mapped to a semantic action-background token. In high contrast mode, the semantic token switches to a near-black value, but the white text on that background now needs a thicker font weight to maintain legibility per WCAG. The focus ring around that button cannot be a soft blue glow; it must be a 2px solid outline with at least 3:1 contrast against both the button and the surrounding canvas. Meanwhile, the arrow icon inside the button, which was a subtle two-tone SVG, needs its secondary fill removed or merged so it does not disappear against the new dark background. You would model all of this in Figma using variable modes for the colors, a boolean property on the button component to toggle the focus ring layer, and a variant swap for the simplified icon asset.