Recent datepicker experience:
1. Control is presented as three separate spin controls, supporting the Up/Down Arrow keys to increment and decrement the value as well as manual typing. But because they're not text inputs, I can't use the Left/Right Arrow keys to review what each separate one contains, only to move between day, month, and year.
2. I tab to year.
3. I press Down Arrow, and the value is set to 2075. I'm unclear how many use cases require the year to be frequently set to 2075, but I can't imagine it's many so this seems like a fairly ridiculous starting point.
4. I press Up Arrow, and the value gets set to 0001. The number of applications for which 0001 is a valid year is likewise vanishingly small.
5. I delete the 0001, at which point my #screenReader reports that the current value is "0". Also not a valid year.
6. Out of curiosity, I inspect the element to see which third-party component is being used to create this mess... only to find that it's a native `<input>` with `type="date"` and this is just how Google Chrome presents it.

A good reminder that #HTML is not always the most #accessible or user-friendly.

#accessibility #usability

reshared this

in reply to James Scholes

wow really that's the native date input for Chrome? It's behaved far better in Firefox for sure. The only downside I think to these becoming standardized in HTML, each browser has a chance to develop their internal version of that control just a bit differently and then you get stuff like this. (I also think it could discourage adoption of the native HTML one if someone already has a custom component in place, since they get more control yet still by keeping it.)