Typography in labels

Labels are not decorative. They are essential navigation cues in forms and interactive components. A well-designed label reduces errors, builds confidence, and makes interfaces accessible to all users.

Typography choices for labels, helper text, and error messages directly affect whether a form is completed successfully. Relying only on placeholder text, using small sizes, or low contrast often results in frustration and accessibility failures.

Principles for setting form and field labels accessibly and consistently.

Always use a visible label

Do not rely on placeholder text as the only identifier. Labels must remain visible when a field is focused or filled.

References:

• Form design – Baymard Institute
• Creating accessible forms – WebAIM
• Placeholders in form fields are harmful – Nielsen Norman Group

Use sentence case for labels

Sentence case improves scanning and accessibility, especially for users with dyslexia. Avoid ALL CAPS or Title Case in form labels.

References:

• UX writing best practices – Google Material Design
• Capitalization – Microsoft Writing Style Guide

Ensure minimum size and weight

Labels should be at least 14px (0.875rem) and medium weight for clarity. Helper and error text may be smaller (12px / 0.75rem) but must remain readable.

References:

• WCAG 1.4.4: Resize text

Provide sufficient contrast

Labels, helper text, and error messages must meet WCAG contrast ratios: 4.5:1 for normal text, 3:1 for large/bold text. Do not use light gray text for active labels.

Use tools like WebAIM contrast checker or built-in design system validators to verify compliance.

References:

• WCAG 1.4.3: Contrast (minimum)
• Contrast checker – WebAIM

Use differentiate label, helper, and error text

Each type of text should have a distinct role:

• Labels: clear, always visible.
• Helper text: smaller, neutral color.
• Error text: same size as helper but high contrast and often red.

References:

• Inclusive front-end design patterns – Heydon Pickering

Align labels consistently

Left-aligned labels above fields are fastest to scan. Inline labels or floating labels should be used carefully and always tested.

References:

• Placeholders in form fields are harmful – Nielsen Norman Group

Frequent pitfalls when case styles are misused in digital products.

Using placeholder text instead of labels

When the placeholder disappears on input, users may forget what the field required.

Labels too small or light

Low-contrast gray labels at 12px / 0.75 rem or smaller are unreadable for many users.

Inconsistent styles for error and helper text

If error text looks identical to helper text, users may miss critical issues.

Using all caps labels

ALL CAPS harms readability and accessibility in forms.

Typography in labels is essential for usable, accessible forms.

• Always use visible labels, never placeholders alone.
• Keep labels at least 14px / 0.875rem, helper and error text at least 12px / 0.75 rem.
• Ensure high contrast and clear differentiation between label, helper, and error text.
• Use sentence case for readability and accessibility.

Good label typography prevents errors, improves form completion, and builds trust.

Scenario: Form label typography

Use when designing the visual style of form labels, ensuring they are readable, clearly distinct from input text, and accessible for all users.

You are a UX-focused design agent. Design form label typography for [form/design system context].

Rules:
- Always use visible labels — never replace with placeholders
  Placeholders disappear when users type, fail contrast requirements, unreliable in screen readers

- Font size: minimum 14px — prefer 16px for primary labels
- Font weight: 500 (medium) — slightly bolder than input text to distinguish them
  Do not use the same size and weight for labels and input text

- Contrast: minimum 4.5:1 against form background
  Do not use light gray that fails — e.g. #999 on #fff = 2.85:1 (fails)
  Disabled labels: maintain at least 3:1

- Content: short and descriptive — 1–4 words, sentence case
  ✓ "Email address" ✓ "First name" ✓ "Date of birth"
  ✗ "Enter your email address here:" (too long, trailing colon)
  No trailing colon after label text

- Required indicator: in the label — "Email address *"
  Never beside or after the field

- Association: every label programmatically linked to its input
  Email address
  

Accessibility:
- Never use aria-label as substitute for a visible label
- Screen reader announcement: "[Label text], [input type], [required if applicable]"

Constraints:
- Never use placeholder text as the only label
- Never style labels to be lighter or smaller than input text
- Never omit the for/id association