<input type="datetime-local"> is tolerable for simple cases, but you can often do so much better than it: showing extra information in the pickers like disabling days that are not permitted (e.g. appointment calendar on a day nothing’s available), and allowing free-form text entry like “3pm” or “next Thursday”, those sorts of things. As it stands, <input type="datetime-local"> and its kith and kin are very restricted and mildly painful to use, by comparison. Perhaps browsers could improve them and make them more flexible and freeformable, but they haven’t done so yet. There’s a reason why very few sites actually use those date/time input types, and I don’t think it’s just their comparative recentness.
Yes, you do want to be careful about accessibility here, but it’s emphatically not a “please please please don’t do this” situation. Because its essence is just a text box, the accessibility of what’s been made here is probably actually excellent, and if it’s not, it should require only minor tweaks to make it so. You very probably actually don’t want to expose the popup in any way—for what I see, doing literally nothing for accessibility will probably be better in most instances than doing something.
> the accessibility of what’s been made here is probably actually excellent
It's not. The whole thing is in a <table>, there's no ARIA attributes let alone ones that reflect states, and the buttons are...<li>'s?
> doing literally nothing for accessibility will probably be better in most instances than doing something
This is a great example of why that's true. If the author had referenced any of the best practices for this, they wouldn't have ended up with such a bad result.
You can add stuff like that, and it’s definitely a legitimate and reasonable approach, but the popup is not functionally necessary, and done fancily even properly stands a fair chance of being just a distraction. If the popup were the only interface then yes, it would be important to optimise accessibility on it, but as it stands I think also it’s a perfectly reasonable option to make the popup entirely inaccessible by keyboard or accessibility tool, and just work with the text box. (This would be paired with things like having Up/Down work to increase/decrease the year/month/date where the cursor is, rather than Up/Down/Left/Right navigating around the calendar table.)
I’d be interested to see what a regular user of accessibility stuff would find of this stuff. I think both approaches are perfectly reasonable, with the don’t-expose-the-popup-at-all side possibly even preferable for some.
In terms of accessible date pickers, I'd refer people to the GOV.UK styleguide which explains what to use when (and by law their stuff needs to be accessible!)
On Linux at least, the Firefox datepicker is pretty terrible to the point of just being broken. The Chromium one is okay I guess, but with some annoyances. I don't know the status on all the other platforms, but that's why I generally just prefer controlling it myself.
Good to see Safari finally added it nine months ago. Small annoyance, but I remember the inputs' values not being consistent either. Is that still the case?
Nope. Not that I could find, not without pulling the repo and installing it somewhere. Quite an oversight. I don't want to watch a video, I want to click on the damned thing.
Coincidentally I built one yesterday at well. Opposite approach. As little code as possible.
First of all
Input type=date
On Android shows a date picker that many users have found confusing to operate. They can't figure out how to select the year. I used to say "not my problem" but it actually was because they still complained.
So
Input type=month
Solves that first problem and then a day selector does the rest but that's an unfamiliar paradigm so...
I wanted year/month/day in a way that uses will find easy. One for each then.
There's many existing options and they use a lot of code. I mean just an insane amount. I don't want a boatload of code to select a date in a way that users won't complain.
The browser already knows everything about dates, so we can just ask it how many days are in a month and what the name of the month is.
Leap years, leap seconds, it's all in there. No wheel reinventing necessary
So we have one of our two key lines
let maxday = new Date(year, month, 0).getDate();
(It'll be further explained at the end.)
2nd part; let's not have an array of month names. Instead, let's ask the browser for what the user calls the months based on their first language:
Intl.DateTimeFormat(
navigator.languages[0],
{month: 'long'})
.format( new Date(startyear, i) )
So they select the year, then the month, then we use that as a query to find out how many days are in the month by asking the default Date object, already built in.
What would improve my quality of life is if date pickers used some global cookie mechanism to share recent dates between websites. The number of times I'm looking at flights/hotels around the web and have to keep entering the same date on infuriatingly different date pickers is soul destroying.
At least allow a date to be pasted in and have the logic to accept if the user has entered something thats different from what the backend needs but makes sense for the the current date and their locale: "22 feb" "22/02/2022" "22/2" "2/22" etc
I can't find a readily accessible demo, but if I could, the first thing I'd do is check to see if there are two 2:00AM options at the relevant local time DST boundary.
Conceptually, it needs to take in account the type of date it handles. The question to ask is “does it matter when in the week or a month a date is selected?” or similar.
Under these considerations, I can say that for a "well known" date, like a birthday, or an expiration date, where the context of the calendar doesn't matter, it's not needed, and probably undesirable. (Under these contexts I would use bare selects/inputs with one for each of YYYY/MM/DD.)
For an appointment, or a time span? Date pickers are useful. “Which days are mondays?” “I want to book from a monday to the friday the next week.” Raw controls won't provide the context to help the user.
I feel the ones you fight against are more than likely those where you already are aware of a precise moment, in the first scenario. The others are more likely to leave no impression if well done.
With that said: Always de-compose the date picker in their discrete parts that a user can use. Make the picker fill these.
Most important thing date picker helps is user doesn't need to understand required input format. Coz there is no standard format across apps and localities.
There is one, it is a standard, it is a format, it is "an international standard covering the worldwide exchange and communication of date- and time-related data". But not everyone uses it.
They are also useful for date range input. Or if the user needs to work out the date by looking at a calendar which is pretty common if you are doing something like booking a holiday or time off work.
They are nice for hotel
and flight bookings to try out different dates, visualize the length of the stay and quickly see what day if the week you are picking.
I think they would be good where additional info
can be inlined such as existing events.
But without those advantages I prefer to type it. Especially date of birth!! A year older is another 10px to scroll!
A competent date picker? Sure. One that has doesn't function as expected, even slightly? Then no.
I like date pickers especially for when I need help deciding a date, e.g. when booking a haircut: I don't know exactly what day I want to go in, but I'll know it when I see it.
Date pickers are also useful for ranges of dates (although the UX for these is hit-and-miss), since it helps visualize duration nicely and always makes it easier to pick an end date.
I'm 50/50 when it comes to a date that I know, but usually, I'll prefer a ISO8601 input field for that.
I don’t particularly have a string opinion on date picker, but I find myself typing in dates when possible. Particularly when entering something like a birthday, so I don’t have to navigate to the prior century first.
There are date/time pickers that let you type in the input field if you click a little area with a calendar icon next to it. Our date/time fields are like that.
Gets more complicated as you need things like like min date, max date and same for time of day, exclusion blocks of time, Start of week day, touch friendly, accessibility friendly
That's not off topic. It's covered in the article - the component enables text entry, and two-way data binding means the calendar widget updates as you type.
You call it over-engineering, I call it good UI. I want to enter the date my way, and the computer can figure out the format. If I type 3 Nov it should know I mean 11 3 2022. Computers are good like that, and a half decent date parser is trivial to write.
Nothing drives me crazy like a credit card number field that tells _me_ to remove the spaces or hyphens from the number. Like what, the computer can't do that for me?
I mostly gave up on date pickers, I prefer entering a datetime as text and if it can automatically figure out the format I'm using then it's godsend. Clicking tiny buttons with unknown behavior takes way too much time
Because most of them lack time, and you need time to store dates in different time zones? This one lacks seconds for instance. Our date/time filelds are in ISO8601 (concatenated with space) so we also need seconds.
"Monday is the first day of the week according to the international standard ISO 8601, but in the US, Canada, and Japan, it's counted as the second day of the week." - https://www.timeanddate.com/calendar/days/monday.html
I've always thought of Monday as the first day of the week. It's the day that starts the workweek (and school week) and Sunday is part of the weekend.
There is really no way to implement this in JS anyway because all major browsers have native date pickers by now: https://caniuse.com/input-datetime