---
title: "Skin-tone representation"
description: "Why the range of skin tones in a health product's imagery is a correctness requirement, not a style preference, and what a set must cover before it ships."
url: "https://opsinjs.pensievelabs.org/foundations/imagery/skin-tone-representation"
source: "https://opsinjs.pensievelabs.org/foundations/imagery/skin-tone-representation.md"
section: "Foundations"
kind: "foundation"
reviewed: "2026-09-20"
reviewer: "engineering"
aliases: ["skin tone", "representation", "diverse imagery", "equity in imagery"]
---
> Elements written as `` below are opsinjs documentation
> components. Their attributes are the content: the values they render are
> generated from `tokens/*.json` and `registry/catalogue.ts` and are
> published separately at https://opsinjs.pensievelabs.org/r/index.json and under the Reference
> section.
> Nothing is missing from this page. The data simply does not live in
> the prose.
## Overview [#overview]
In most products, the range of people shown in the imagery is an inclusivity
question: important, but a matter of who feels welcome. In a health product it is
also a **correctness** question, and that is why this page exists as a
requirement rather than as advice.
The mechanism is straightforward. A great many clinical signs are described, and
illustrated, by how they change the appearance of skin. Redness is the obvious
one: inflammation, rashes, allergic reactions, cellulitis, sunburn. On pale skin
those present as red. On brown and black skin they frequently do not. The same
conditions may present as purple, grey, darker brown, or as a change in texture
or warmth with little visible colour change at all.
So an image set that shows a condition on one skin tone is not merely
under-representative. For every reader whose skin is a different tone, it is
**wrong**: it shows them something that does not look like what they would see,
and they may reasonably conclude they do not have it.
This page argues a position and cites no study. The presentation difference
described above is standard dermatological knowledge, but if your product shows
clinical imagery, that imagery needs review by somebody clinically qualified,
across the range of skin tones you intend to serve. A design system cannot do
that review and should not be read as having done it.
## How it works [#how-it-works]
**The requirement, stated so it can be checked:**
1. **Any image set showing people covers a genuine range of skin tones**, not two
points at the extremes. A set of six figures in which five are pale and one is
not has met a quota and not the requirement.
2. **Any set showing a clinical sign covers the range for that sign**, or it
does not ship. This is the correctness half, and it is stricter: a single
illustration of a rash is worse than no illustration, because it is confidently
wrong for most of the world's readers.
3. **Skin tone is not correlated with role across the set.** If the figures
demonstrating good technique are pale and the ones demonstrating errors are
not, the set is making a statement whether or not anyone intended it. Check the
set as a whole; individual images cannot reveal this.
4. **Interface colour is not derived from skin tone.** A product must never use a
reader's skin tone to select a theme, a category colour or anything else.
**A tone scale is a tool, not the requirement.** Recording which tones a set
covers against a published dermatological scale is what makes coverage
checkable and gaps visible, and it is the practical way to run point 2. It does
not by itself satisfy anything: a set can cover a scale evenly and still fail
point 3.
**Illustration and photography have different obligations.** An illustrated set
can be produced across tones from the same drawing, which makes coverage cheap and
therefore inexcusable to skip. A photographic set cannot, which is a real cost and
one of the stronger reasons to illustrate rather than photograph. See
[Illustration style](./illustration-style.mdx).
**Avatars are a separate problem** and are covered on
[Avatars and identity](./avatars-and-identity.mdx). A default avatar with a skin
tone assigns one to everybody who has not chosen.
## Using it [#using-it]
**Audit the set, not the image.** Representation is a property of the collection.
Lay every image out together and ask three questions: what range is covered, is
tone correlated with role or with outcome, and which reader would find nobody here.
A rash-comparison surface that shows the same condition across a documented
range of skin tones, each labelled with what to look for on that tone. The
labelling includes the cases where colour change is the wrong thing to look
for and texture or warmth is the sign.
A single illustration of a red patch on pale skin, captioned "what a rash
looks like". For most readers in the world it is not what a rash looks like,
and the caption asserts that it is.
**Describe what to look for, not only the colour.** Text is where this is
actually solved. "Warm, swollen and tender, and darker or more purple than the
skin around it" works across tones in a way that "red" does not.
**Do not let a default become a norm.** Where one image has to stand for a
concept, rotating a default is not a solution and neither is picking a mid-tone as
a compromise. Either the concept needs several images or it does not need one.
**Commission for coverage from the start.** Retrofitting range into an
illustration set means re-drawing it. Putting the requirement in the brief costs
nothing; discovering it after delivery costs the set.
**Do not ask readers to self-identify a skin tone to get correct information.**
Where the product genuinely needs it because it is showing a clinical
comparison, the tone is asked for once, explained, optional and revocable, and
it is health data subject to
[consent and disclosure](../../health/consent-and-disclosure.mdx).
## Tokens [#tokens]
There are no skin-tone tokens and there will not be. Skin tone is content, and
tokenising it would put a fixed palette of human beings in a stylesheet.
Interface colour and depicted skin tone are unrelated systems and must stay that
way.
## Accessibility impact [#accessibility-impact]
* **This is an accessibility failure in the plain sense**, not only an equity one:
information present for one group of readers is absent for another, and the
absent group cannot tell that anything is missing.
* **Text alternatives carry more weight here than anywhere else.** A description
that says what to look for reaches every reader, including those using a
screen reader and those whose skin the image does not depict. The signs that
are not colour changes are part of what that description says. See
[Alt text and descriptions](../../content/alt-text-and-descriptions.mdx).
* **Never rely on colour change alone to describe a sign.** This is principle 2
from [Principles](../principles.mdx) in an unexpected place: colour is an
unreliable channel here for a reason that has nothing to do with the display.
* **Clinical imagery needs a warning and an explicit control to reveal**, across
every tone, for the reasons on [Photography](./photography.mdx).
* **Coverage should be recorded and published**, so that a gap is a known gap
rather than an unexamined one. This is the same posture as
[the accessibility statement](../../accessibility/accessibility-statement.mdx).
## Related [#related]
* [Illustration style](./illustration-style.mdx) explains why illustration makes
coverage affordable, and what to put in the brief.
* [Inclusive content](../../content/inclusive-content.mdx) is the wording side of
the same requirement.
* [Body diagrams](./body-diagrams.mdx) is where representation and clinical
accuracy meet most directly.