To reduce the cognitive load and effort for users, pre-select a good default date. To choose a good default date, some options and considerations include:
Sometimes if it is necessary for the user to make a conscious choice, you might not provide a pre-selected good default. In that case, you'll need to provide clear and specific validation feedback.
Where it makes sense, provide text below the Date Picker to provide placeholder info about the accepted date format. Avoid using HTML
placeholder text to show date formats because it can be inaccessible to some people using screen readers. See the Product language style guide dates section for details on presenting date formats, such as
Mmm DD, YYYY.
For selecting a date far in the future or past compared to the default, you might consider using a Select component instead.
You might consider providing shortcut buttons that select specific relative dates if they are common choices.
When a user selects a single date, close the visual calendar.
When a user first selects a date, set the start date in the range.
When a user selects a second date, close the visual calendar.
To prevent errors, you might disable dates before or after dates that don't make sense. For example, an employee cannot start at a company before they are born, so for selecting a start date, you might disable dates before their date of birth. To do this, you might set a "min" date or a "max" date. See the Interaction states guidelines.
To help people recover from errors, you might instead allow dates that don't make sense and then show validation errors so people know what they need to change. Sometimes it can be easier to make a minor adjustment to an incorrect date than to start over. For example, if the user has selected the right month but was off by 1 day, it might be easier to adjust it by 1 day than to have that date rejected and need to select the month and day again.
By default, we immediately update the date value when a user selects the date or dismisses the visual calendar popover, a little like autosaving. For some circumstances, you might instead choose to provide "Update" and "Cancel" buttons in the popover if the risk and impact of errors is high. For example, if selecting the wrong date as a filter for some data would immediately cause the data to reload and performance is an issue, you might choose to include buttons to prevent frustration with slow interfaces.
All text used in the Date Picker, including the calendar days, month, year, buttons, and text field, needs to be localized. For more information, see the Localization guidelines.
We show weeks starting on Sundays.
Some people might find using a Date Picker difficult. Let people use the text field or visual calendar to select dates.
See WAI ARIA: Date Picker Dialog Example for more details.
When the Date Picker has an error, show the error Text Field state and provide a meaningful validation error message that tells people how to recover from the error.
For selecting a date and time, use a Date Picker and adjacent Time Picker using a Text Field.
The resulting value in code for a selected date includes the year, month, and day, but not the time.
On mobile devices, you might choose to use a native date picker component instead of the visual calendar popover.
Here are some examples from elsewhere: