4 ms·

> Also, they could've just... set a default date of like Jan 1, 1960 and saved 90% of their users a headache I'm not sure how that really helps? Moving multipl

> Also, they could've just... set a default date of like Jan 1, 1960 and saved 90% of their users a headache I'm not sure how that really helps? Moving multiple years is still going to be a huge pain, so you're only really saving people who have a birthdate in or very close to that same year.

culi 4y ago
Right then other things they could do: - provide some helpful text explaining to users how to switch between years - use an external library with a custom date picker The reason why I wouldn't recommend the approach they went with is because there's all sorts of aria-related properties and semantic meaning for screen readers that type="date" carries. This is especially relevant for the target audience they're talking about. I guess the third option is - what they did but actually try it with a screenreader yourself. Make sure your aria labels make sense and is navigable for both keyboards and screenreaders (two separate issues). Also make sure you're replicating the validation logic that type="date" gives us for free. Basically replicate all the complex HTML5 logic and semantics
- seb1204 4y ago
  Such text will likely not be read by many. I think I will read it as I am generally a reader of how-to or help files to get a better idea of features. However the rest of my family you would need to point out the explanation text and likely also 'force' them to read it. They much rather tap around in the hope for the desired outcome.