Use currentColor for Matching Labels, Borders and Inline Icons

Set the component’s foreground color once

A theme change should not require replacing three unrelated hard-coded values if the label, border and icon are meant to match. Give the component a color, then refer to that foreground where matching is intended. The color property is inherited and supplies the value to which currentColor resolves. [1]

This is a dependency rule, not a palette recommendation. Choose the role and its actual reading surface first. You can still assign a separate icon color when the design calls for it, but record that exception instead of treating it as a failed theme.

Use a complete component with explicit matching parts

<style>
 .component { color:#285f66; border:3px solid currentColor;
   padding:1rem; display:inline-flex; gap:.7rem; align-items:center; }
 .component svg { width:24px; height:24px; fill:currentColor; }
</style>
<div class="component">
 <svg viewBox="0 0 24 24" role="img" aria-label="Square sample">
  <rect x="2" y="2" width="20" height="20" rx="3"></rect>
 </svg>
 <span>Component label</span>
</div>

Here the border refers to the component’s color. The inline SVG is given an explicit currentColor fill and inherits its color in this example. Its simple square is an original demonstration mark, not a product icon or a claim that every imported SVG already uses this rule. [1] [2]

Resolve currentColor on the element that uses it

currentColor means the value of the color property on the same element. It does not search for a convenient brand color elsewhere in the document. If a descendant inherits the component color, the dependency produces a match; if a more specific rule gives that descendant its own color, currentColor follows that local value instead. [2]

Scroll inside the table on a phone. Keyboard readers can focus the region and use the arrow keys.

The live record reads computed color, border color and fill from this example. It does not infer them from the checkbox wording alone. Inspect those same values on a real component when a result differs.

Find the rule that breaks the intended dependency

Start with the element that looks wrong. Check its computed color and its actual paint property. A directly assigned fill:#8C2033 is a different rule from fill:currentColor; a currentColor fill with color:#8C2033 can produce the same red appearance through another dependency. Read both properties before editing the palette.

Then check where the rule comes from: an inherited value, a more specific class, an inline style or a state rule. Remove or revise an unintended override. If the difference is intentional, preserve it in the component specification and verify that it remains understandable in every relevant state.

Do not assume changing color recolors every kind of visible glyph. CSS Color 4 describes special behavior for fonts with built-in colored glyphs, including some emoji. This example uses an explicit inline geometric fill and does not test all font or asset formats. [1]

Keep color matching separate from complete component review

Matching parts can still be faint on their actual background. Check the label’s foreground/background pair and any needed border or meaningful icon against its adjacent colors. They answer different visibility questions. A successful dependency is not a complete interaction or accessibility result.

Record the base color role, paint property, inheritance rule, permitted overrides and the states checked. Keep that note beside the brand usage record and component contrast review. A future theme change should preserve intended relationships while triggering the relevant pair checks.

Try two complete review cases

These are original teaching cases, with the assumptions stated in each question.