Date input

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?