I'm a screen reader user and, hands down, date pickers are the controls which cause the most frustration for me on the web because of their almost universal lack of accessibility. In some cases, far too many to be considered reasonable, I've been unable to complete a booking or similar process because I simply can't choose a date. But yet, in an article about creating the perfect control, accessibility is barely even mentioned, certainly not in any menaingful enough way to actually create an accessible one.
> 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.
Does the browser's built in date picker work well with accessibility? I would assume so, but since I only have to follow rules and not use a screen reader, I'd like to know how the actual experience is.
I have moved to using only the browser's built in date picker, living with the limitations for benefit of future proofing.
How would you prefer such a control handle both textual input of date, but also support a visual "pop-up" calendar widget for those who want it? Is the main problem the lack of standard conventions and consistency for the selecting input method, or is it having no known textual input option?
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.
Consider using basic/native HTML date and time pickers which are mostly supported by all major browsers besides desktop Safari instead of overengineering.
It's a long article, but there's actually a section called "Where Does This Leave An OS’ Native Date Picker?" That links to exactly what you've linked here, and describes some considerations for when you might not want to use them:
"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
I think the native date picker is okay for dashboards, internal tools, or similar cases where supporting 87% of users (based on browser) with an inconsistent experience is okay.
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?
IMO, the easiest way is text boxes: [DD] [MM] [YYYY] [HH] [MM]. Old people just don't 'get' dropdowns and calendar controls. It can't be perfect unless everyone can use it. Native controls don't meet the criteria because people use browsers which don't support those controls.
The native ones don't consistently/easily support "mm/dd/yyyy" formats, and many customers want that.
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.
Am I the only one that thinks that the new Android time picker is way worse than the old one? Selecting the time by finding hours and minutes on two dials is much slower than pushing 4 numbers on a number pad, because I know the 4 digits, I know a numberpad but my brain has to do the extra work of finding the hours on a not completely familiar double dial.
I've been trying to figure out a good way to create a date picker for a user's birthdate, and coming up short.
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.
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.
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.
A consideration if you're making an accessible website is keyboard navigation. Having numerical inputs eliminates this, however. Still a good read, I have been thinking a lot about date pickers in the last year.
[+] [-] jscholes|7 years ago|reply
> 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.
[+] [-] RobertRoberts|7 years ago|reply
I have moved to using only the browser's built in date picker, living with the limitations for benefit of future proofing.
[+] [-] tabtab|7 years ago|reply
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.
[+] [-] Traubenfuchs|7 years ago|reply
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
https://caniuse.com/#search=time%20input
[+] [-] habitue|7 years ago|reply
"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
[+] [-] jitl|7 years ago|reply
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?
[+] [-] billysielu|7 years ago|reply
[+] [-] tabtab|7 years ago|reply
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.
[+] [-] styfle|7 years ago|reply
[+] [-] Numberwang|7 years ago|reply
[+] [-] Reedx|7 years ago|reply
[+] [-] Zardoz84|7 years ago|reply
[+] [-] ifightcrime|7 years ago|reply
[+] [-] saudioger|7 years ago|reply
[+] [-] pmontra|7 years ago|reply
New: https://i.imgur.com/8a4R16O.jpg?1
Old: can't find a picture, it was four digits HH:MM above a number pad.
[+] [-] gregable|7 years ago|reply
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.
[+] [-] brlewis|7 years ago|reply
https://flems.io/#0=N4IgzgpgNhDGAuEAmIBcIB0ALeBbKIANCAGYCWMY...
[+] [-] kalleboo|7 years ago|reply
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
[+] [-] ummonk|7 years ago|reply
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.
[+] [-] a_r_8|7 years ago|reply
[+] [-] jscholes|7 years ago|reply
When would you not be?
[+] [-] hotcrossbunny|7 years ago|reply
[+] [-] mesozoic|7 years ago|reply
[+] [-] wudu|7 years ago|reply