UX Patterns Guide
UI + UX Input And Data Entry standard

Date input

Ask the date question once, group visible day/month/year fields under that question, provide a valid example, accept common month forms, validate parts together, preserve typed values, and submit a canonical date only after validation passes.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users already know the exact date or can look it up easily.
  • The service needs day, month, and year as one date answer.
  • Users benefit from fast keyboard entry and part-specific correction.
  • The product can validate impossible dates and preserve typed parts.

Avoid when

  • Users are unlikely to know the exact date.
  • Users need to schedule against availability or compare calendar days.
  • The answer is approximate, partial, or naturally expressed in words.
  • The valid choices are a small controlled set better represented by select or radio options.
  • The implementation cannot group the fields accessibly or validate dates semantically.

Problem it prevents

Users often know an exact date, but a single ambiguous field, rigid mask, long year selector, or calendar widget can make entry slower, harder to correct, or inaccessible.

Pattern anatomy

What a strong implementation has to make clear

User need

The date is exact and already known, memorable, or easy to look up from a document.

Pattern promise

Ask the date question once, group visible day/month/year fields under that question, provide a valid example, accept common month forms, validate parts together, preserve typed values, and submit a canonical date only after validation passes.

Required state

Empty untouched grouped date fields with legend, hint, and visible part labels.

Recovery path

Screen reader users hear Day, Month, Year without hearing the date question.

Access contract

Group the three inputs in a fieldset with a legend that states the full date question.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A passport issued question uses a fieldset legend, hint example 27 3 2007, separate Day, Month, and Year labels, numeric input mode, and a group error that names the missing year.
  • A date of birth field uses bday-day, bday-month, and bday-year autocomplete attributes and still lets users type 7 Jan 1984.
  • A user types 7 Jan 1984, sees month normalized to 01, submits, and reviews canonical value 1984-01-07.
  • A user enters 31 2 2026, sees an impossible-date error, fixes only the day, and keeps the month and year values.
Weak implementation

Vague, hidden, hard to recover from

  • A single date field shows DD/MM/YYYY inside the input and removes the only instruction when users start typing.
  • Three tiny boxes auto-advance focus after two characters and announce only Day, Month, Year without the date question.
  • A user pastes a known birth date into a masked field and the interface discards separators and jumps focus unpredictably.
  • A user must open a calendar and navigate decades to enter a birthday they already know.
UI guidance
  • Render day, month, and year as separate text inputs inside one fieldset with a legend that asks the full date question and a hint containing a valid example date.
  • Size day and month fields for short values, year for four digits, keep labels visible for each part, and apply error styling to the group and any failing part.
UX guidance
  • Use date input when users already know the exact date or can look it up without needing calendar context.
  • Preserve every typed part, tolerate common month names, normalize to a canonical date only after validation, and explain exactly which part is missing, impossible, or out of range.
Implementation contract

What the implementation must handle

States

  • Empty untouched grouped date fields with legend, hint, and visible part labels.
  • Focused day, month, or year field without auto-advancing to the next part.
  • Partially filled date that preserves other parts while the user edits one part.
  • Month-name typed state normalized for validation and canonical storage.

Interaction

  • Typing, paste, selection, deletion, undo, and correction happen inside each part without automatic focus movement.
  • Tab follows normal page order from day to month to year and then to the next control.
  • The legend gives the full date question; Day, Month, and Year labels identify each part.
  • Hints and errors are associated with the grouped date control and failing parts where possible.

Accessibility

  • Group the three inputs in a fieldset with a legend that states the full date question.
  • Use visible labels for Day, Month, and Year and do not rely on format text inside the fields.
  • Associate the hint and group error with the date input group.
  • Do not automatically move focus between fields.

Review

  • Does the user already know this exact date, or do they need calendar context?
  • Will the example date be valid and unambiguous for this question?
  • Can users type month names, paste, and correct one part without focus jumps?
  • Which part-specific and semantic date errors can occur?
Interactive lab

Inspect the states before you copy the pattern

Enter a known exact date

Fill day, month, and year parts, type a month name, trigger missing and impossible-date errors, review canonical ISO output, and compare a broken auto-tabbed mask.

Date input
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Empty untouched grouped date fields with legend, hint, and visible part labels.

Keyboard / Access

Tab moves from day to month to year in normal order.

Avoid Generating

Using one freeform field with disappearing format instructions.
Evidence trail

Source-backed claims behind this guidance

GOV.UK Design System: Date input

Government Digital Service - checked

GOV.UK date input guidance supports known-date use, grouped fields, fieldset legends, examples, month-name tolerance, no auto-tabbing, and errors.

U.S. Web Design System: Memorable date

U.S. Web Design System - checked

USWDS memorable date guidance supports manual date-part entry and distinguishes scheduling tasks that may need a date picker.

Full agent/debug reference

Problem Context

  • The date is exact and already known, memorable, or easy to look up from a document.
  • The service needs day, month, and year rather than an approximate period or scheduling availability.
  • Users may type numeric dates, month names, leading zeros, pasted values, or partially complete values.
  • The form needs precise error recovery for missing day, missing month, missing year, impossible dates, and dates outside allowed ranges.
  • Birth-date entry may benefit from browser autocomplete attributes that identify day, month, and year separately.

Selection Rules

  • Choose date input for exact dates users already know or can find quickly.
  • Use a date picker for scheduling, availability, date-range exploration, or tasks where calendar context helps decision making.
  • Use ordinary text input for approximate answers such as Spring 2026, about 10 years ago, or unknown month.
  • Use select only when the valid date part values are a small meaningful set, not for arbitrary historic years.
  • Do not use an input mask that blocks month names, paste, correction, or part-specific validation.
  • Use a single question in the legend and separate labels for Day, Month, and Year.
  • Use an example date that is valid for the requested date and follows local order.
  • Accept full and abbreviated month names where users may type them.
  • Validate complete date semantics, not only numeric field lengths.
  • Use birth-date autocomplete attributes only for the user's own date of birth.

Required States

  • Empty untouched grouped date fields with legend, hint, and visible part labels.
  • Focused day, month, or year field without auto-advancing to the next part.
  • Partially filled date that preserves other parts while the user edits one part.
  • Month-name typed state normalized for validation and canonical storage.
  • Missing day, month, or year error state naming the missing part.
  • Impossible date error state for combinations such as 31 February.
  • Out-of-range error state when the date violates service bounds.
  • Valid submitted state showing canonical ISO date and original visible parts.
  • Birth-date autocomplete state when collecting the user's own date of birth.
  • Mobile numeric keyboard state for numeric day, month, and year entry.

Interaction Contract

  • Typing, paste, selection, deletion, undo, and correction happen inside each part without automatic focus movement.
  • Tab follows normal page order from day to month to year and then to the next control.
  • The legend gives the full date question; Day, Month, and Year labels identify each part.
  • Hints and errors are associated with the grouped date control and failing parts where possible.
  • Month names and abbreviations are accepted when unambiguous and normalized for validation.
  • Submitting validates missing parts, numeric ranges, month names, impossible dates, and service date bounds together.
  • A successful submission stores a canonical date such as YYYY-MM-DD while preserving visible local part order.

Implementation Checklist

  • Define the date being requested, expected order, allowed range, accepted month names, canonical storage format, and whether birth-date autocomplete applies.
  • Build a fieldset with a legend, hint, and three labelled text inputs for day, month, and year.
  • Use inputmode numeric for numeric fields while keeping text input behavior flexible enough for editing and paste.
  • Do not automatically tab between date parts; let keyboard and assistive technology users control focus.
  • Validate missing parts, impossible dates, leap years, range boundaries, and future or past constraints on client and server.
  • Keep typed values visible after validation errors and put errors near the group before the part inputs.
  • Test screen readers, keyboard tab order, voice input, paste, browser autofill, mobile keyboards, localization, zoom, and server-returned errors.

Common Generated-UI Mistakes

  • Using one freeform field with disappearing format instructions.
  • Using a date picker for a birthday or document date users already know.
  • Auto-tabbing between day, month, and year fields.
  • Rejecting month names even though users naturally type Jan or January.
  • Validating only field length and accepting impossible dates.
  • Showing Invalid date without saying which part needs correction.
  • Using a year dropdown with hundreds of options.
  • Applying birthday autocomplete attributes to dates that are not the user's own birthday.

Critique Questions

  • Does the user already know this exact date, or do they need calendar context?
  • Will the example date be valid and unambiguous for this question?
  • Can users type month names, paste, and correct one part without focus jumps?
  • Which part-specific and semantic date errors can occur?
  • What canonical date does the backend receive, and how are local date orders handled?
  • Should this be approximate text, a date picker, or a range control instead?
Accessibility
  • Group the three inputs in a fieldset with a legend that states the full date question.
  • Use visible labels for Day, Month, and Year and do not rely on format text inside the fields.
  • Associate the hint and group error with the date input group.
  • Do not automatically move focus between fields.
  • Use autocomplete attributes only where they accurately identify the user's own date information.
  • Keep error text specific enough for screen reader and keyboard users to know which part to fix.
Keyboard Behavior
  • Tab moves from day to month to year in normal order.
  • Typing two digits does not move focus automatically.
  • Arrow keys, selection, Backspace, Delete, copy, paste, undo, and redo behave like ordinary text inputs.
  • Submit with an error returns focus to the group or first failing part without clearing other parts.
  • Month-name entry does not require a picker or mouse interaction.
  • Escape does not clear the date unless a separate reversible clear action is provided.
Variants
  • Known document date
  • Date of birth
  • Memorable date
  • Past event date
  • Future deadline date
  • Date input with month-name tolerance
  • Date input with birth-date autocomplete
  • Date input with missing-part error
  • Date input with impossible-date error
  • Date input with range validation

Verification

Last verified: