Select

Choosing one value from a known set. The component's defining risk is not how it opens — it is what it says before anyone has chosen.

Overview

A select looks like a low-stakes control and behaves like a high-stakes one, because it always shows something. Whatever is in the closed trigger reads as an answer, and if the form is submitted without the clinician ever opening it, that answer is recorded as theirs.

Everything below follows from that: an unanswered select must look unanswered, options must be readable in full, and no clinical value is ever pre-chosen.

Anatomy

Options

• Never truncate. "Left ventricular hypertroph…" and "Left ventricular hypertrophy with strain" are different findings. Options wrap; the list widens; the label gets shorter. Nothing gets an ellipsis.
• Order by clinical likelihood, not alphabetically, where a defensible ordering exists — and state the ordering in the hint if it is not obvious.
• Group when there are more than about seven, using real group semantics.
• Add search above about fifteen. Below that, search costs more than it saves.
• Include an explicit "Other" with free text wherever the list could be incomplete — a clinician forced into the nearest wrong option produces worse data than one who can type.
• Never disable options without saying why. Same rule as Interaction states.

Options that look alike

A select presents its options in a small box, in a list, read quickly, often by someone who already believes they know which one they want. That is the worst possible presentation for a pair of names that differ by two letters — and clinical vocabularies are full of them.

Look-alike and sound-alike names are a recognised medication-safety hazard with published lists behind it, and a dropdown concentrates every condition that makes them dangerous: small type, tight leading, alphabetical order that puts the confusable pair next to each other, and a reader scanning rather than reading.

• Type-ahead is a hazard here, not a convenience. Typing three letters and landing on whichever confusable name sorts first is exactly the failure this section is about. Where a list is long enough to need typing, it needs a search with visible results — not a jump.
• Never rely on the reader noticing. The clinician who picks the wrong one is not being careless; they are reading quickly under interruption, which is the specified context of use, not an aberration from it.
• A confusable pair is a finding for the risk file. If two options in a list can be mistaken, that is a use-related hazard under IEC 62366-1 with an identifiable mitigation, and it belongs in the file rather than in a designer's judgement.

What a dropdown must not grow into

Every feature below is offered by mainstream systems, each solves a real problem, and each turns the control into something other than a way of choosing one value from a known set.

The pattern is the one from Menu: a transient surface accumulates features because it is convenient to put them there, and each addition costs a protection the surface was never designed to provide. A dropdown that needs a filter, columns and a link is a panel that has not admitted it.

Native or custom

A custom select that is merely prettier than the native one is not worth its accessibility surface. Reach for it when the requirement genuinely exceeds what native offers.

States and validation

• Unanswered is a state, not an error — until submission is attempted. Then it becomes an error naming the field and moving focus to it.
• Changing a selection never clears other fields. Where a change genuinely invalidates dependent input, say so and confirm before discarding anything typed.
• Loading options is visible. An empty list while a fetch is in flight is indistinguishable from a list with no options; show the pending state and, on failure, say the options could not be loaded rather than presenting an empty set.
• Read-only shows the chosen value at full contrast with no caret — it is information, not an unavailable control.

What the component enforces, and what it only asks for

A native <select>, deliberately — which means the platform holds more here than usual, including one behaviour this page argues against and cannot remove.

Do's and don'ts

Accessibility

• Native first. The most accessible select is the one the platform provides.
• Custom listboxes implement the full pattern — role="combobox" on the trigger with aria-expanded, role="listbox" and role="option" with aria-selected, arrow-key navigation, Home/End, type-ahead, Esc to close, and focus returning to the trigger.
• Group headings use real semantics, so screen-reader users hear the grouping rather than a stray option.
• The listbox is reachable at 200 % zoom and repositions inside the viewport instead of clipping.
• Selection is not colour alone — the selected option carries a check as well as a fill.
• Touch targets: options obey the physical floor from Scaling, which usually means fewer visible at once on a cart. That is the correct trade.

Outcomes of use

What this contributes to, in the terms of Usability & context of use. These are attributes believed to contribute to an outcome; the outcome itself is settled by observing real use in a specified context, not by this page.

• Effectiveness — the recorded value is one the clinician actually chose. Silent defaults are the failure mode this component owns.
• Efficiency — the right option found without reading the whole list; clinical ordering and grouping do more for this than search does.
• Satisfaction — confidence that the form says what they meant, and no sense of having been answered on their behalf.

Clinical safety notes

• No pre-selected clinical value. (you) Mitigates: a default recorded as a clinician's decision without being seen.
• Options never truncated. (the component) Mitigates: two similar findings being indistinguishable at the point of choosing.
• "Other" with free text where the list may be incomplete. (you) Mitigates: forced mis-classification into the nearest wrong option.
• Failed option loading is stated. (you) Mitigates: an empty list read as "no applicable options".
• Changing a selection never silently clears input. (you) Mitigates: loss of typed clinical text.
• Native control on touch. (the platform; it is a native select) Mitigates: mis-selection when gloved or one-handed.

Implementation

$ npx shadcn@latest add https://md.notjustany.tech/r/select.json

<Select
  label="Infusion"
  hint="Strength and route are part of the option"
  placeholderOption="Choose an infusion"
  options={[
    { value: "dobu", label: "DOBUTamine 250 mg/20 mL · infusion" },
    { value: "amio", label: "Amiodarone 300 mg/10 mL · IV bolus" },
    { value: "dopa", label: "DOPamine 200 mg/5 mL · infusion" },
  ]}
/>

// Options are flat data with no icon slot and no link item, so a dropdown
// cannot grow into a navigation surface.

What the component takes. This table used to list placeholder, clinical, searchable, optionsError — props the component does not have, and never had. Found by the registry gate’s props-table rule.

Related

• Text field — labels, hints and validation behaviour.
• Clinician override — the reason list in context.
• Interaction states — disabled versus read-only.
• Scaling & displays — option target size.