6 ms·
It's been a while, but I'm not convinced there is a truly accessible date picker out there. Allowing manual typing of the date seems like the best and only viab
by ryathal 3y ago
It's been a while, but I'm not convinced there is a truly accessible date picker out there. Allowing manual typing of the date seems like the best and only viable option.
- SoftTalker 3y agoAlso just typing the date manually is almost always faster than using a date picker. Or at least that's how I perceive it, which is all that matters. I hate apps that force me to take my hands off the keyboard and use the mouse.
- SilasX 3y agoYep. They increasingly break addons that (try to) enable me to do everything from the keyboard.
- Tempest1981 3y agoFor motel stays, it's nice/reassuring to see/select by day-of-the-week.
- astrospective 3y agoAlso every year I get a little more resentful of spinner wheels for year of birth that start at the current year.
- wizofaus 3y agoAs soon as we solve the whole US-using-a-different-date-format-to-the-rest-of-the-world problem, absolutely. Having it automatically display the day of the week as you type the date would be a big help though.
- amalcon 3y agoThe problem is that "just typing the date manually" actually has quite complex i18n issues. It can be done well, but that generally means you make the user explicitly confirm the date they just typed.
- uses 3y ago<input type="date"> is a pretty good option, and it lets you type in the date manually if you'd like.
- tjoff 3y agoSomewhat agree, but when you say typing the date you mean ISO 8601, right? That is the only sensible format for dates, and while all developers probably agree on that it isn't a given that all your users will.
- cxr 3y agoAs input, any permutation of full year, full month name, and day of the month is unambiguous wrt any date on or after January 1, 100 CE* and therefore sensible, no matter how unusual/obscure. (The issue of handling multiple languages isn't a rejoinder to this, because that's just localization, which is an umbrella that should already exist so treating it like a new requirement would just be double counting.) This is how every browser-native datepicker should already work, although regretfully they do not. * 32 CE, if you want to really get down to it
- tjoff 3y agoNoone would expect that so you'd need to explain it and get people to spell correctly. Not convinced it is a good UX. "Just localization" isn't "just". Many people have the wrong localization on their computers. Partly because they don't always communicate in their native language. But also because google et. al. are doing such a piss poor job of it. It is also always weird if your are on an international site. Enter everything in English and then suddenly is expected to enter some fields in your native language.
- cxr 3y ago> Noone would expect that You are moving the goalposts. > "Just localization" isn't "just". Many people have the wrong localization on their computers. Think about this for a minute longer. Do you have an example or scenario for the use of a Web site where the author can fall into a pit of success (despite having the user's wrong localization) on all things except for dates and that would be broken by allowing* this date input method? Even ignoring that: What I said was that "any permutation of full year, full month name, and day of the month is unambiguous". There are a finite number of months and a finite number of localized tokens for representing those months. Do you have an example of two different locales that use the same token (or token sequence) to denote different months on the calendar? * the word "allowing" playing a crucial role here