---
title: "Ask users for ethnicity"
description: "Optional, explained, self-identified, and never used to adjust a clinical threshold without a named clinical owner."
url: "https://opsinjs.pensievelabs.org/patterns/ask-users-for/ethnicity"
source: "https://opsinjs.pensievelabs.org/patterns/ask-users-for/ethnicity.md"
section: "Patterns"
kind: "pattern"
reviewed: "2026-09-20"
reviewer: "clinical"
aliases: ["ethnicity field", "ethnic group question", "race field", "health equity data"]
implements: ["field", "disclaimer-note", "term"]
---
> 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.
## When to use [#when-to-use]
There are two legitimate reasons to ask, and they call for different handling.
* **Equity monitoring.** Checking that your product works as well for everyone
who uses it. This is a good reason, it is the more common one, and it does not
require the answer to affect anything the individual reader sees.
* **A clinical purpose with a named owner.** Some risk calculators and reference
ranges have historically been adjusted by ethnicity. This is contested
clinical ground, several such adjustments have been withdrawn in recent years,
and it is not a decision a design system may take. If your product does this,
a named clinician owns the decision and it is documented on your own
thresholds page. See [Reference ranges](../../health/reference-ranges.mdx).
If you cannot name which of the two you are doing, you are not ready to ask.
## When not to use [#when-not-to-use]
* **You have no analysis plan.** Collecting equity data you never analyse is
extraction, not equity. Decide what you will look at before you add the field.
* **You want it as a personalisation input.** Ethnicity is not a preference
signal. Using it to decide what content to show is a decision that will
eventually be read out loud in a room you would rather it were not.
* **You mean nationality, language, or country of birth.** Those are different
questions with different answers, and one of them is usually what a product
actually needs.
* **The reader is mid-task and worried.** Never ask this on a results screen or
inside a symptom flow. It belongs in a profile, at a moment of the reader's
choosing.
## How it works [#how-it-works]
{`flowchart TD
A["We want ethnicity data"] --> B{"Equity monitoring, or a clinical adjustment?"}
B -->|"neither can be named"| C["Do not ask"]
B -->|"equity"| D["Optional field in the profile, with an analysis plan"]
B -->|"clinical"| E{"Is a named clinician accountable for the adjustment?"}
E -->|"no"| F["Do not adjust; do not ask"]
E -->|"yes"| G["Ask, explain the adjustment, and let the reader see it"]
D --> H["Self-identified, multi-select, prefer not to say, free text"]
G --> H`}
Rules:
* **Always optional, always with "prefer not to say".** In a health product this
question has a history that makes refusal a reasonable and common response.
* **Self-identification only.** Never infer it from a name, a postcode, a
language setting or anything else. Inference here is both unreliable and
offensive.
* **Multi-select, with free text.** People have more than one ethnicity, and
every fixed list excludes somebody. Offer a list because it makes analysis
possible, and allow an answer outside it because accuracy matters more than
tidy data.
* **Use a recognised classification for the reader's country**, and say which
one you are using. Categories differ substantially between national schemes.
A list built for one country is confusing and sometimes insulting in another.
Do not invent your own.
* **Never let the answer silently change a number.** If ethnicity adjusts a
threshold, the adjustment is visible to the reader, attributed, and
explicable. A reader who changes their answer and watches their result change
with no explanation has been shown something they cannot interpret.
* **Say what it is used for, in one sentence, at the field.** And make it true.
## Content [#content]
"Your ethnic group (optional). We ask so we can check that this product works
as well for everyone who uses it. It does not change anything you see, and
you can skip it."
"Ethnicity \*". The field is required, unexplained, mid-signup, with a
five-item list and an "Other" radio.
Where an adjustment genuinely applies: "This calculation is adjusted for
ethnicity. Here is what it uses and why," with a link to the clinical source
and the name of the group that owns it.
Applying an adjustment invisibly, so the same reading produces two different
results depending on an answer given eighteen months ago in a settings
screen.
Sensitive-question wording is owned by
[Asking sensitive questions](../../content/asking-sensitive-questions.mdx).
## Accessibility [#accessibility]
* **No autofill token exists** for ethnicity. Use `autocomplete="off"` and do
not invent one.
* **A multi-select is a `fieldset` of checkboxes with a `legend`** carrying the
question, not a listbox. Readers need to see the options to answer this
honestly.
* **"Prefer not to say" is an explicit option**, mutually exclusive with the
others, and its exclusivity is announced rather than silently enforced.
* **Free text is a labelled field**, revealed by an option whose label says a
text field will appear, so the change is not a surprise to a screen-reader
user.
* **The explanation precedes the options** and is part of the group's accessible
description.
* **Long lists need a heading structure or grouping**, not a single flat list of
forty options. National classifications are often nested, and the nesting is
meaningful.
## Research [#research]
National statistical agencies publish ethnicity classifications and the
research behind their wording; use the one for the country your readers are in
and cite it, rather than composing a list. We deliberately do not reproduce
any classification here. They are country-specific, they change, and copying
one into a design system is how an out-of-date list spreads.
The position that ethnicity-based clinical adjustment requires a named
accountable clinician is ours and is opinion, though it is a conservative one:
several such adjustments have been re-examined and withdrawn in recent years,
and a design system is not the right layer to encode any of them. Our rule is
procedural rather than clinical. We do not say whether an adjustment is right,
only that a design system may not make it silently and that the reader must
be able to see it.
What would change our mind: nothing on visibility or on optionality.
## Updates to this page [#updates-to-this-page]