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
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
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!
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!
Apr 9, 2020 ยท 2:08 PM UTC
1

