Designing the Perfect Date and Time Picker | Hacker News Reader

Designing the Perfect Date and Time Picker

smashingmagazine.com

93 pointspmontra42 comments

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.

For date selection, I use a standard <input type=text>, and a dropdown icon to the right of that covered by an invisible <input type=date tabindex=-1>, with JavaScript for validation and syncing the two inputs.

This:

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).

I'm fond of a little icon that I have to click to get the popup. If I just mouse into a field, I don't like it to auto expand anything around it.

Firefox does that automatically these days if you set the input's type to date.

But if you have to target multiple browser brands, that's probably not a practical solution. A JavaScript library is more likely to be consistent across browsers. I don't like relying on 3rd party JavaScript gizmos, but it may be the least of evils.

I'd be more than happy to discuss this further with you or your organisation. Feel free to get in touch, my email is in my profile.

Consider using basic/native HTML date and time pickers which are mostly supported by all major browsers besides desktop Safari instead of overengineering.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

https://caniuse.com/#search=time%20input

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.

Hey, I'm an "old people" by some standards ;-) How about just saying, "people who are still new to computers" or the like. Don't have to mention age. My rule of thumb is to be PC unless there's a good reason not to. Politeness should be the default. Experience tells me Dale Carnegie is right about effective groups far more often than Yosemite Sam's approach. (The President is a Sammer.)

lol I take your point. I don't really mean people new to computers though, more those who continue to struggle over the long term. Typing into boxes is easier to figure out than all other field types.

what do you mean with "lol"?

I don't want to turn HN into Twitter, so I'll politely decline to get into it.

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.

How can Safari go this long without implementing this part of the HTML5 standard? Is there even a ticket to implement?

That's a good question. Why is the company that ranks 4. place in the Fortune 500 index unable to implement basic, boring but useful HTML 5 features in their desktop browser that were implemented by Opera nearly 10 years ago, while at the same time implementing them on their mobile browser?

It looks like they just gave up:

https://bugs.webkit.org/show_bug.cgi?id=78746

https://bugs.webkit.org/show_bug.cgi?id=88026

Are they unable? Of course not. Is desktop Safari in any way a priority to them? Not really, at this point.

A long-shot, but could they be waiting for convergence of desktop and mobile in MacOS? With the upcoming Mojave, they're taking a small step in that direction. Not an excuse for these delays dating back 5+ years, but maybe an interesting question.

> could they be waiting for convergence of desktop and mobile in MacOS?

Maybe, but... honestly, that's not really good enough.

They probably care very little about desktop Safari. There are few persuasive business reasons to care about it at this point. macOS as a whole seems to be considerably deprioritized.

It's too bad these can't pick up local preferences of input format.

I see the date input the German/European/sane way in Chrome, like this: "18.07.2018", unlike shown on the mozilla screenshots. Is that what you mean?

Yes that's what I mean. I'm Swedish and it does not follow the Swedish input standard which I much prefer to any other.

Handy for internal tools, but unfortunately a pretty weak choice for most things public facing.

well, you can find that for some use cases, aren't very user friendly. Try to input a date of the XIX century.

But then what do you do for desktop safari?

Depends on your market, but if you're in enterprise software, it's a small percentage of your typical userbase, and of those nearly all have access to a good browser like Chrome or Firefox available anyway, so the upside of going out of your way to support Safari is not high.

Support is rather abysmal.

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.

New: https://i.imgur.com/8a4R16O.jpg?1

Old: can't find a picture, it was four digits HH:MM above a number pad.

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.

Three inputs type="number"?

https://flems.io/#0=N4IgzgpgNhDGAuEAmIBcIB0ALeBbKIANCAGYCWMY...

On iOS, using the date input field gives you the date wheels which work well https://docs.microsoft.com/en-us/xamarin/ios/user-interface/...

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

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.

> A consideration if you're making an accessible website

When would you not be?

Unfortunately, almost always. Approximately zero percent of websites take accessibility into account in any real way.

A sitter for the kids, good restaurant, fine food and a glass of wine with my...er.. time picker. Oh wait. Damn punctuation!

95% of the time letting the user input a date string and validating it is best.

How would you validate / resolve 02-03-15? Is it Mar 2nd or Feb 3rd? Date picker solves this.

Reply on news.ycombinator.com