Label

Common Label Variants

Label Anatomy

Required Field Patterns

Label Properties

Important: The htmlFor attribute (React's equivalent of HTML for) must exactly match the id on the form control. If they don't match, clicking the label won't focus the control, and screen readers won't associate them. This is the #1 label bug in production code.

Design Token Mappings

Labels are deceptively token-light — most of their visual weight comes from typography tokens. The critical design decision is weight differentiation: labels should be visually distinct from body text (often medium weight vs regular) but not compete with headings (never bold/semibold unless it's a legend).

Label States

Floating Label States (Detailed)

Floating labels must transition smoothly. Use transform: translateY() and font-size transitions (150–200ms ease) rather than changing top/position to avoid layout thrash.

Accessibility

Labels are the foundational accessibility element for forms. Getting them wrong breaks the experience for screen reader users, voice control users, and users with motor impairments.

Programmatic Association (WCAG 1.3.1 – Info and Relationships):

• Every form control MUST have a programmatic label — either via <label for="id">, nesting the control inside <label>, or using aria-label/aria-labelledby
• The for/htmlFor attribute must exactly match the control's id. Test this: click the label — if the control doesn't focus, the association is broken
• For groups of related controls (radio buttons, checkbox groups), use <fieldset> with <legend> instead of individual labels for the group title

Visible Labels (WCAG 2.5.3 – Label in Name):

• The accessible name of a control must contain the visible label text. If the label says "Email" but aria-label="user email input field", voice control users saying "click Email" won't match
• Don't override visible labels with different aria-label text — it creates a disconnect between visual and programmatic labels

Target Size (WCAG 2.5.8 – Target Size Minimum):

• Labels expand the click target of their associated control. This is especially valuable for small controls like checkboxes and radio buttons — the label makes the entire text area clickable
• Ensure the label + control combined target is at least 24×24 CSS pixels (WCAG 2.5.8 Level AA)

Color Contrast (WCAG 1.4.3 – Contrast Minimum):

• Label text must achieve 4.5:1 against its background. Use the Contrast Checker.
• Helper text and optional indicators (often color-text-secondary) frequently fall just below 4.5:1 — test these explicitly
• Required asterisks in red must meet 4.5:1, but since they're supplementary (the required attribute provides programmatic indication), some teams accept 3:1 for the asterisk alone

Error Identification (WCAG 3.3.1 – Error Identification, 3.3.2 – Labels or Instructions):

• Error messages must be programmatically associated with their control via aria-describedby
• The error message ID referenced by aria-describedby must exist in the DOM
• Don't rely solely on color to indicate errors — add text, icons, or border changes
• Required fields should be indicated both visually (asterisk or text) and programmatically (required or aria-required="true")

Placeholder is NOT a Label (WCAG 1.3.1, 3.3.2):

• Placeholder text disappears on input and is not reliably read by all screen readers — it cannot substitute for a label
• Floating labels that start as placeholders must transition to a visible, persistent label state once the field has value — the label must remain visible at all times after activation

Usage Guidelines

Do:

• Provide a visible label for every form control — no exceptions
• Use <label> with htmlFor/for matching the control's id — this is the most reliable association method
• Place labels above inputs for forms (fastest scan pattern per UX research) or inline for checkboxes/radios
• Use clear, concise label text: "Email address" not "Please enter your electronic mail address below"
• Indicate required fields consistently — pick one pattern (asterisk, text) and use it throughout the application
• Include a legend at the top of forms explaining your required indicator: "Fields marked with * are required"
• Associate error messages with controls using aria-describedby

Don't:

• Don't use placeholder text as a label replacement — it disappears and is unreliable for accessibility
• Don't use aria-label when a visible label is feasible — visible labels benefit all users, not just screen reader users
• Don't change label text dynamically based on input value — it confuses screen readers that cache the accessible name
• Don't put interactive elements (links, buttons) inside labels — clicking them may trigger the associated control
• Don't use ALL CAPS for labels — it reduces readability by 13–18% (Miles Tinker's legibility research) and screen readers may spell out each letter
• Don't remove labels to save space — visually hide them with .sr-only if space is truly constrained

Design System Implementations

Material Design (MUI) integrates labels into form components via the label prop on <TextField>, <FormControlLabel> (for checkboxes, radios, switches), and <InputLabel> (standalone). MUI's floating label is the default behavior: the label animates from inside the input to above it on focus. The <FormHelperText> component handles helper and error messages. MUI automatically generates matching id and htmlFor associations. The shrink prop controls whether a floating label stays in its "floated" position.

Ant Design uses the <Form.Item label="..."> wrapper which renders a <label> with automatic htmlFor association to the nested control. The required prop adds a red asterisk. Validation messages appear via rules on <Form.Item>, with error text rendered below the control. Ant supports tooltip on Form.Item for inline help icons. The label positioning (labelCol/wrapperCol) uses Ant's grid system for horizontal form layouts.

Chakra UI provides <FormLabel> which renders a <label> with Chakra's typography styling. The <FormControl> wrapper manages isRequired, isInvalid, and isDisabled states, propagating them to <FormLabel>, <Input>, <FormHelperText>, and <FormErrorMessage>. Chakra's required indicator defaults to a red asterisk via the requiredIndicator prop, customizable to any ReactNode. All id and aria-describedby associations are generated automatically.

Bootstrap styles <label> via the .form-label class (margin-bottom: 0.5rem, inline block). Floating labels use the .form-floating wrapper: the label is placed after the input in source order and positioned via CSS. Bootstrap's .form-text class handles helper text. Required indicators, error messages, and validation styling are handled via Bootstrap's validation classes (.is-invalid, .invalid-feedback).

Apple Human Interface Guidelines emphasizes that every control needs a clear, concise label. In SwiftUI, labels are first-class: TextField("Email", text: $email) — the first parameter is the label. Toggles, pickers, and steppers all take label parameters. Apple recommends title case for labels and advises against using the label to repeat the data type ("Email" not "Email text field"). On iOS, labels are visually integrated into the control row in form lists.

Tailwind CSS relies on native <label> elements styled with utility classes: block text-sm font-medium text-gray-700 mb-1 for standard labels, sr-only for visually hidden labels. There is no Label component — Tailwind is utility-first. Required asterisks: <span class="text-red-500">*</span>. Error messages: <p class="text-sm text-red-600 mt-1">. The Headless UI and Radix UI libraries (commonly used with Tailwind) provide <Label> primitives with automatic association via context.