---
title: "Required and optional"
description: "Mark one or the other but never both. In a health product, prefer marking optional, because it makes the cost of every required field visible."
url: "https://opsinjs.pensievelabs.org/patterns/forms/required-and-optional"
source: "https://opsinjs.pensievelabs.org/patterns/forms/required-and-optional.md"
section: "Patterns"
kind: "pattern"
reviewed: "2026-09-20"
reviewer: "engineering"
aliases: ["required fields", "optional fields", "asterisk convention", "marking required"]
implements: ["field", "log-sheet", "consent-sheet"]
---
> 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]
Read this once, decide once, and apply the decision to every form in the
product. The failure here is not choosing wrongly; it is choosing twice.
There are three defensible conventions:
1. **Mark required fields.** Sensible when most fields are optional.
2. **Mark optional fields.** Sensible when most fields are required. That is
the normal case in a health product, because a form that asks for things it
does not need should have had the fields removed.
3. **Mark nothing, because everything is required.** Only honest when it is
true, and it is worth stating in the intro that it is true.
opsinjs recommends **(2), marking optional**, for a specific reason: it makes
each required field carry its own justification. When "optional" is the marked
case, adding a required field is a visible act. When "required" is the marked
case, the asterisks multiply and nobody notices.
## When not to use [#when-not-to-use]
* **Do not apply this to consent.** Consent is never "required" in the form
sense. If the reader cannot decline, it is not consent. See
[Consent and permissions](../consent-and-permissions.mdx).
* **Do not apply it to a validated instrument.** Its own instructions govern
which items may be skipped, and re-labelling them is a change to the
instrument.
* **Do not use it as an alternative to deleting the field.** The first question
is always whether to ask at all. See
[Form design](./index.mdx) and each page in
[Ask users for…](../ask-users-for/index.mdx).
* **You want the code.** Schema-level requiredness is
[Handbook → Forms](../../handbook/forms.mdx).
## How it works [#how-it-works]
{`flowchart TD
A["A field on the form"] --> B{"Can the reader proceed without it?"}
B -->|"no"| C{"Is that genuinely true, or just convenient for us?"}
C -->|"convenient"| D["Make it optional, or remove it"]
C -->|"genuinely required"| E["Leave it unmarked under the marked-optional convention"]
B -->|"yes"| F["Label it 'optional' in the visible label text"]
F --> G{"Does skipping change what the reader gets?"}
G -->|"yes"| H["Say what changes, next to the field"]
G -->|"no"| I["No further explanation needed"]`}
Rules:
* **The word, not a symbol.** "(optional)" in the visible label. An asterisk is
a convention the reader has to be taught, is frequently not announced, and is
usually explained in a legend they scrolled past.
* **The marker is inside the label element**, so it is part of the accessible
name: "Notes (optional)".
* **Never mark both.** A form with asterisks on required fields and "(optional)"
on the others has two systems and is ambiguous about the fields carrying
neither.
* **`required` on the control matches the label.** The visual and the
programmatic must agree; if the schema says required and the label says
optional, the reader finds out at submit.
* **Skipping has a stated consequence when there is one.** "Optional. Without
it we'll compare your readings to a general adult range rather than one for
your age" is a decision. A bare "(optional)" on a field that quietly degrades
the product is not.
* **Do not fake requiredness to improve data quality.** Making a field required
because the analytics team wants it produces worse data, not better: readers
enter something rather than nothing.
## Content [#content]
Label: "Anything else you want to add (optional)". The word is in the label,
the reader needs no legend.
Label: "Notes" with a small grey asterisk beside "Weight" three fields up and
a note at the top reading "\* indicates a required field".
"Your ethnicity (optional). We ask because some reference ranges differ, and
it helps us check the product works equally well for everyone. You can skip
it."
"Ethnicity \*" is required, unexplained, and reads as gatekeeping in a
health context. See [Ethnicity](../ask-users-for/ethnicity.mdx).
## Accessibility [#accessibility]
* **The marker is in the accessible name.** Screen-reader users hear "Notes,
optional, edit text" without needing to have found a legend.
* **Use the `required` attribute** (or `aria-required` where the native
attribute is unavailable) so the state is programmatically determinable, and
make sure it matches the label.
* **An asterisk with no accessible text is meaningless.** If a design demands
one, the label must still contain the word, and the asterisk must be
decorative.
* **Do not rely on colour or weight** to distinguish required from optional;
WCAG 2.2 SC 1.4.1 and the general colour-independence rule both apply. See
[Colour independence](../../accessibility/colour-independence.mdx).
* **Do not announce requiredness twice.** A label containing "(required)" *and*
the `required` attribute produces a double announcement in several
combinations. Under the marked-optional convention this does not arise, which
is a further small argument for it.
* **Requiredness must not be discovered only at submit.** WCAG 2.2 SC 3.3.2
(Labels or Instructions) is the floor.
## Research [#research]
Marking optional rather than required is a recommendation, not a finding. The
argument we actually rely on is organisational rather than perceptual: making
"optional" the marked case creates friction in the right direction, because
adding a required field to a health form should be a decision somebody has to
defend.
The prohibition on bare asterisks is better supported and less arguable. An
asterisk is a learned convention with no accessible text, and its explanation
is conventionally placed where a reader using a screen reader meets it last.
What would change our mind: evidence that readers complete forms faster or
more accurately under a marked-required convention in forms that are mostly
required, which is the case where our recommendation costs the most.
## Updates to this page [#updates-to-this-page]