Date input

On this page

Anatomy

States

Designer guidance

Developer guidance

Content editor guidance

Accessibility 

Support

Anatomy

States

Designer Guidance

When to use

Use the date input component when users need to provide a specific date (e.g. date of birth, appointment date).

When not to use

Avoid using a date input component when:

• Users need to select a range of dates: use a date picker or range selector instead.
• Users need to select approximate dates: when users are unlikely to know the exact date, use a text input instead.

How to use

• Labels: Always provide a visible label above the input. Use sentence case and make it clear what data is expected. 
• Help text: Use help text below the label to add additional context (e.g. “Enter date as DD/MM/YYYY”).
• Required: Indicate if the field is required.
• Placeholder text: Do not rely on placeholder text for instructions.

Behaviours

• Error messages appear when invalid or incomplete dates are entered. 
  • The error message should be clear, concise and written in plain English. The message must explain what has happened and how the user can fix it. 
  • Avoid general errors such as ‘An error occurred’. An error for a specific situation is more helpful.
  • Do not apologise as does nothing to help with the problem.
  • Frequency of errors should be tracked to help with testing and research.
• Focus state must be clearly visible.
• Use the disabled state to show that a date input exists, but is currently unavailable.
  • Do not allow users to interact with, or submit content in a disabled input.
  • When the user hovers over a disabled date input, display a not-allowed cursor.
• Indicate required fields clearly in the UI (e.g with the word “Required” or an asterisk and supporting text).
  • Do not rely on colour alone to show required status.

Developer Guidance

Best practices

• Use semantic HTML. 
• Associate labels with inputs.
• Use <aria-describedby> for additional instructions or error messages.
• Use <aria-required="true"> for required fields so this is information is accessible assistive technology users.
• Do not rely on placeholder text for instructions.
• Ensure keyboard operability and logical focus order.
• Apply visible focus styles and maintain minimum target size (44×44px).

Content Editor Guidance

Best practices

• Labels should be short, clear, and descriptive (e.g. “Date of birth”).
• Provide help text separately for date formate e.g. DD/MM/YYYY (not as placeholder).
• Avoid jargon or ambiguous terms.
• Keep instructions concise and actionable.

Accessibility

Accessible date inputs must:

• Always use a visible label for each input.
• Do not use placeholder text as a substitute for labels.
• Provide additional instructions using <aria-describedby> when necessary.
• Required fields must be communicated to all users:
  • Visual: Clear text indicator (e.g “Required or asterisk”).
  • Programmatic: <aria-required="true">.
• Ensure sufficient colour contrast for text and borders.
• Inputs must be operable via keyboard and have visible focus indicators.

WCAG success criteria

• 1.3.1 Info and Relationships (Level A)
  Labels programmatically associated with inputs.
• 1.4.3 Contrast (Minimum) (Level AA):
  Text and borders meet contrast requirements.
• 2.1.1 Keyboard (Level A):
  Fully operable via keyboard.
• 2.4.6 Headings and Labels (AA):
  Labels describe purpose clearly.
• 3.3.2 Labels or Instructions (A):
  Provide clear instructions for input and indicate required fields before submission.

Related components

Text input

Checkboxes

Radio buttons