Label

​

When to use

• Every Input, Select, Combobox, Textarea, Checkbox in a group, Radio in a group, or similar form control needs one.
• When grouped menu items would benefit from a label.

​

When not to use

• Headings or section titles - use the appropriate heading level.
• Descriptive text below or alongside a field — use Helper text.
• Non-interactive UI labels like status indicators or metadata — use plain text or Badge.

​

Dos and don’ts

• Do always associate a Label with its field via htmlFor / id — this is what makes it accessible, not just visual.
• Do mark required fields consistently across the form, either with an asterisk or explicit text.
• Don’t use placeholder text as a substitute for a label — placeholders disappear on input focus and aren’t accessible.
• Don’t hide labels to create a “cleaner” layout — if space is tight, use Tooltip to supplement a shortened label, not replace it.
• Don’t disable a label independently of its field — their states should always match.

​

Often used with

​

Accessibility

• Explicit programmatic matching: Pass a unique id to the form input and match it explicitly on the label using htmlFor="input-id".
• No nested focusables: Avoid placing clickable controls (for example, modal triggers, Tooltip triggers, or external links) inside the <Label> tag, which disrupts standard focus wrapping and assistive click handling.
• Visually hidden fallback: If a design requires omitting a visual label, render the <Label> with a screen-reader-only utility class (className="sr-only") rather than removing the label element entirely.
• Contrast standards: Maintain at least a 4.5:1 contrast ratio against the background, even when styling optional or disabled field labels.
• Grouped controls: Use <legend> inside a <fieldset> (or role="group" with aria-labelledby) instead of standalone labels when grouping related controls like Radio groups or Checkbox lists.

​

Visual examples

​

Disabled

​

With asterisk

​

Required field