Datepickers are one of my least favorite interfaces, and I've written them in vanilla ja, Angular, and React and it never gets better. They have a ton of globalization and accessibility issues that will bite you. One of the big ones? Use of color to identity date classes. #a11y
Smashing Magazine ๐Ÿ‡บ๐Ÿ‡ฆ ๐Ÿณ๏ธโ€๐ŸŒˆ @smashingmag
8 Apr 2020
Everything I think about when I think about date pickers. #uxpatterns 01 โ€” Date picker, a date-range picker or a time picker? 02 โ€” Should it be activated when a user clicks on input/icon? 03 โ€” Should we combine day/month/year into one input field?
2
1
1
Old school response from a salt and pepper white chin hair gal but server-side tech maybe? #JustThrowingSpaghetti
1
Dates and numbers are two of the most troublesome data types for internationalization. There are a couple front-end input methods that are configurable and accessible, but when you tie a calendar control to them it becomes 10x harder.
1
Replying to @hrobertking
Makes sense. But impressive projects clearly are a strength for you. BBC for sure has had to manage massive amounts of data, large internationalization with accessibility and dates and numbers. I wonder if there's a resource there? Working with clashes in the tech itself? Yikes!

Apr 9, 2020 ยท 1:56 PM UTC

1
Replying to @mholzschlag
There are ways to do it, and I devote a fair amount of space to it in my book, but there's a lot to consider for something that's of questionable benefit other than it looks pretty and everyone has one.
1
1
Even in accessiblity on its own, a solution for one is a barrier for another. Internationalization, same! Tough stuff. My old brain goes to SemWeb? Lucene? Good gracious even Perl!
1