https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local There's a pretty agressive timeout when entering values in this field type. Eg: 1. Highlight the year 2. Press '2', year changes to 0002 3. Wait a couple of beats, like a user who isn't massively confident with the keyboard 4. Press '0', year changes to 0001 If you don't leave a beat between steps 2 & 4, the year will be 0020, which is more expected. This is particularly problematic for the year, hour, and minute, since there isn't really a non-keyboard alternative to selecting those.
The current timeout is 1 second after the previous keypress, which matches the timeout used by NSDatePicker (the native date input on macOS). I agree that a slightly larger timeout would be nice, but I think we will want to continue to match the native behavior. I will need to see if there is willingness to change this behavior system-wide.
I understand the aim for consistency, but it seems like that native date picker is a bit… out of date. It doesn't seem to follow modern design practices across the OS, eg the design is really tight. It's probably worth getting some internal accessibility folks to take a look at it, because someone with a motor impairment (even a temporary/situation one) will struggle to use this input.
If Apple truly cares about accessibility then the right thing to do in this scenario is an end to end review of the date picker including NSDatePicker and making a decision based on metrics, analytical data rather than relying on historical precedent of a potentially faulty user experience to guide decision making.
<rdar://problem/91345351>
*** Bug 249782 has been marked as a duplicate of this bug. ***