> Making one of those date pickers accessible isn’t trivial, because date selection should be keyboard-accessible and you would need to toggle between open and collapsed states. You can find an overview of accessible date pickers. Also, consider looking into Whatsock’s examples.
Great. An important topic reduced into a paragraph which sounds like it was written during the planning stage of the article and never expanded on.
I have moved to using only the browser's built in date picker, living with the limitations for benefit of future proofing.
Our organization is interested in improving our accessibility without sacrificing the convenience of modern GUI widgets, and finding it really tricky and expensive to get both. We are not made of cash, and the problem frustrates everyone.
1. Works well with tabbing (especially problematic on iOS which populates a blank input with today's date on "tabbing" through)
2. Allows user to type in date
3. Allows user to use the browser native date picker
4. Can be made to work progressively
5. Allows user to type in date even if browser has broken support for type=date (still a common problem).
"The problem with native date pickers is that they are very limited in their design and functionality. For example, it’s impossible to add any details such as availability or pricing to a native date picker to avoid zero-results pages. It’s also impossible to select a date range and highlight the connection between two dates because it doesn’t provide a calendar overview."
I think the title is a bit misleading, it sounds like they're going to design the perfect date-picker widget, but instead it's a giant catalog of design considerations that vary for different reasons for requiring date input. Basically, you probably don't want a one-size fits all picker, you'll want to adapt it to your particular problem domain
On a revenue funnel, especially for consumers, you should pick out a component with wider bowser support and consistency:
- Those desktop Safari users are more affluent, and probably represent a more significant opportunity then they do browser market share, especially in the US.
- The inconsistent quality of the date pickers will skew your numbers between users on different browsers. Noticing 15% fewer customers buy when using Edge? Is it because you have an Edge-specific bug, or is it just the weird date picker?
One general design decision about date-pickers is if the target date range is large, such as birth-date, then one needs an easy & obvious way to select or scroll the year also, not just month-by-month.
It looks like they just gave up:
Maybe, but... honestly, that's not really good enough.
Old: can't find a picture, it was four digits HH:MM above a number pad.
Most date pickers assume that the date is in the near future and that the "day of week" context (ie: tuesday) is useful to the user is selecting the date.
Birthdays are the opposite. They are typically decades in the past, the user doesn't know or care what day of the week they are, and the user knows the numerical date by heart.
The only things I've come up with are:
1) Text entry that attempts to accept different formats and displays the formatted parse of the format next to it. Decent on desktop, text entry on mobile is poor.
2) Big array of Years / Month / Day buttons. The possible range of years is limited (nobody alive was born in year 1200) to a little over 100, so this does scale. User simply needs to tap on the correct button 3 times, which is nice, but the picker takes up sooo much visual space.
On desktop the standard for forms seems to be either 3 text fields (Y/M/D) or 3 dropdowns with the possible Y/M/D numbers in them
Why not the standard MMDDYYYY (or DDMMYYYY depending on localization) format (with intervening static / /) that every credit card or user information form uses? Number entry on mobile is very easy.
When would you not be?