Color And Icon Fonts

Colour and icon fonts

Two capabilities the rest of the pack assumes away: type that carries more than one colour, and glyphs that carry non-letter meaning. Both are font technology, both have sharp accessibility edges, and both are chosen far more often than they should be.

1. When to invoke

• Type must render in more than one colour, with gradients, or as a 3D/layered effect.
• Choosing between an icon font and inline SVG.
• Emoji rendering, sizing, or weighting.
• A colour font renders as flat black in some browsers.
• Icons or emoji are announced wrongly by a screen reader.

Do not invoke for ordinary text colour (that's CSS color) or for choosing a text face (typeface-selection).

2. Required context

• What the colour is doing — brand expression, information, or decoration. Only the first two usually justify the cost.
• Which browsers must render it correctly, and what the acceptable degradation is.
• Whether the glyphs are decorative or meaningful (drives the a11y treatment).
• Whether the text must remain selectable, searchable, and translatable.
• Icon count, and whether icons change at runtime.

3. Invariant principles

• Colour fonts degrade, they don't fail — but the degradation is the design decision. Plan what the flat-colour fallback looks like, because some readers will only ever see that.
• Never let colour carry meaning alone. Same rule as everywhere else; a colour font doesn't exempt you from WCAG 1.4.1.
• Icons that carry meaning need an accessible name; icons that are decorative must be hidden from assistive technology. There is no third option.
• A glyph is not a picture to a screen reader. An icon-font character is usually announced as a meaningless codepoint from the Private Use Area, or as nothing at all.
• Layered type must stay legible in one colour. If the layers only resolve into readable letters when all colours are present, the fallback is illegible.

4. Context-dependent heuristics

Layer fonts vs. colour fonts

Stocks: they are different but "effectively work towards the same goal: to move beyond 'flat' colors when setting type."

Layer fonts are ordinary font files that "break out different layers into styles." You duplicate the text, set each copy in a different style, and overlay them — each layer in its own colour. Chouquet's Lustik uses a Back style of hand-drawn squares and a Front style of abstract shapes that only read as letters once combined. Clarke's Rig Shaded ships Face, Extrude, Shadow, and two Shading styles that build a three-dimensional object. Blend modes on the layers extend this further.

• Pros: total control per layer; works anywhere; each layer is a normal font.
• Cons: duplicated text nodes (an accessibility and DOM problem on the web), brittle alignment, and the text is repeated for screen readers unless hidden.
• On the web: acceptable for a one-off display headline; not for body or UI. Mark all but one layer aria-hidden="true".

Colour fonts keep everything in one file — no duplicated text — at the cost of per-layer control.

font-palette is the reason COLR matters. It lets a page select a palette from a colour font, and @font-palette-values lets you override individual entries or define your own:

@font-palette-values --brand {
  font-family: "Nabla";
  override-colors: 0 #1a1a1a, 1 #e63946;
}
.headline { font-family: "Nabla"; font-palette: --brand; }

This is COLR-only. It means one font file can be re-themed per brand or per dark mode without shipping another file.

Icon fonts vs. SVG

Default to SVG. Icon fonts were a workaround for an era without good SVG support, and they carry real defects:

Choose an icon font only when you genuinely need glyph behaviour — icons inline in text that must inherit font-size, color, and baseline alignment automatically, across a very large icon set. Then:

• aria-hidden="true" on the glyph, with a real text label adjacent, or role="img" plus aria-label.
• Never put meaning only in the glyph.
• Provide a fallback so a failed font load doesn't erase the UI.

Emoji. Stocks' point in §89 is that icons and symbols "are like type — and often are fonts," and they behave like type: Noto Emoji ships weights whose stroke thickness changes to suit context. Practical notes: emoji render per-platform and you do not control the artwork; they carry a screen-reader name that is often verbose (🎉 → "party popper"); and they should never be the sole carrier of meaning or state.

5. Failure patterns

6. Evaluation procedure

1. State what the colour or icon is for. Decorative → hide it from AT. Meaningful → it needs a text equivalent.
2. Render in a browser without COLRv1 support (Safari) and confirm the flat fallback is acceptable, not broken.
3. Render with fonts blocked entirely. Icons and layered type must not take the interface with them.
4. Run a screen reader over it. Nothing should be announced as a codepoint, and nothing meaningful should be silent.
5. Check contrast of the rendered result — gradients mean the ratio varies across the glyph; test the worst point.
6. Grayscale it. Does anything stop making sense?
7. Weigh the payload against the number of glyphs actually used.
8. If re-theming is needed, confirm font-palette works rather than shipping a second file.

7. Output format

Purpose: <brand expression | information | decoration>
Technique: <layer font | COLRv1 | OT-SVG ✗ | bitmap | SVG | icon font>
  because <reason>
Fallback (no COLR support): <what renders> — acceptable: <yes/no>
Fonts-blocked behaviour: <what renders>
A11y: decorative → aria-hidden | meaningful → <accessible name>
Contrast at worst point: <ratio>
Palette themable: <font-palette | baked in>
Payload: <n> KB for <n> glyphs used

8. Examples

Brand wants a gradient, dimensional headline face.

Two routes. A layer font like Rig Shaded gives per-layer control — Face, Extrude, Shadow — but on the web it means duplicated text nodes, so all but one copy needs aria-hidden and the alignment is brittle at fluid sizes. A COLRv1 colour font keeps it to one text node with real gradients, and font-palette lets dark mode re-theme it without a second file. Recommending COLRv1 — but the deciding question is Safari, which falls back to a single solid colour. Design that flat state first and confirm the brand still holds; if it doesn't, the effect is wrong for this surface regardless of technique.

"Should we use an icon font or SVG for our 40 product icons?"

SVG. Forty icons doesn't justify the icon-font tradeoffs: PUA codepoints that screen readers mangle, icons disappearing entirely if the font fails, single-colour only, and shipping the whole set to use a subset. The one case that would flip this is icons inlined mid-sentence that must inherit size, colour, and baseline automatically — that's genuine glyph behaviour and SVG handles it worse. Not the case here.

9. Counterexamples

• ❌ "Use an OT-SVG colour font for the hero." — Chromium has said it will never support OT-SVG. Most of your traffic gets flat colour.
• ❌ "Colour fonts degrade gracefully, so no fallback design is needed." — The fallback is a design state; Safari users only see it.
• ❌ "The icon is obvious, it doesn't need a label." — Obvious to sighted users looking at it. A screen reader gets a codepoint.
• ❌ aria-hidden="true" on an icon that is the button's only content. — Now the button has no accessible name at all.
• ❌ "We'll ship two font files for light and dark palettes." — font-palette and @font-palette-values re-theme one COLR file.
• ❌ Layering four copies of a headline in the DOM with no aria-hidden. — The headline is read four times.
• ❌ "✅ means the step is complete." — with no text saying so.

10. Source citations

• Stocks, Universal Principles of Typography — §89 "icons & symbols are like type — and often are fonts" (Noto Emoji's weights changing stroke thickness to suit context); §90 "expand your palette with layer fonts & color fonts" — layer fonts and colour fonts "effectively work towards the same goal: to move beyond 'flat' colors when setting type"; layer fonts "break out different layers into styles" so you "duplicate our text box and select a different style for each one"; Chouquet's Lustik (Back/Front styles resolving into legible characters) and Clarke's Rig Shaded (Face, Extrude, Shadow, Shading building a three-dimensional object); blend modes; colour fonts keeping all options in one file.
• Current standards take precedence on support. COLRv1 renders in Chromium, Firefox, and Samsung Internet; Safari falls back to a single solid colour. Chromium has stated it will not support OpenType-SVG; Firefox has signalled it may drop it. COLRv1 carries a paint graph (linear/radial/sweep gradients, transforms, compositing, blending) plus variation data for the colour construction itself. MDN — font-palette, @font-palette-values.
• WCAG 2.2 §1.1.1 (non-text content), §1.4.1 (use of colour), §1.4.3 (contrast).