4 ms·

Actually the Firefox and Chrome date pickers look... exactly the same I don't think this is so much a problem of UI not being consistent as us just not providi

by culi 4y ago

Actually the Firefox and Chrome date pickers look... exactly the same I don't think this is so much a problem of UI not being consistent as us just not providing resources to help elderly navigate the web better. Also, they could've just... set a default date of like Jan 1, 1960 and saved 90% of their users a headache <input type="date" value="1960-01-01" /> Edit: ok, not "exactly" the same but functionally very similar. Or at least they'd have the exact problems pointed out in the post. See for yourself: FF: https://blog.nightly.mozilla.org/files/2017/06/input_date_calendar_1.png https://blog.nightly.mozilla.org/files/2017/06/input_date_ca... comparison: https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U2YQnUMato21MzzbR.png?auto=format&w=1600 https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U...

RussianCow 4y ago
> 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.
Someone1234 4y ago
> Actually the Firefox and Chrome date pickers look... exactly the same They look nothing alike though. Are you trying all three on iOS? On iOS Apple only allows a single rendering engine (WebKit), so Apple dictates what the <input type="date" /> entry dialog looks like, and there's nothing other "browsers" on the platform can do to fix it (since they're just shells built on top of WebKit).
- culi 4y ago
  Hmm I'm on a macbook. I assumed the component was a browser implementation, but maybe MacOS somehow overrides that? Would you mind providing a screenshot of how it looks on a different OS? Edit: I've google around and I'm only finding UI that looks the same so now I'm very curious about what UI you're seeing that looks different. What browser and OS are you on if you don't mind me asking?
  - deleted 4y ago
    [deleted]
  - Semaphor 4y ago
    Windows: Firefox https://i.imgur.com/j8djrhN.png https://i.imgur.com/j8djrhN.png Chrome https://i.imgur.com/mmBInsQ.png https://i.imgur.com/mmBInsQ.png Both different, both slightly better (because it's clearer the year field is a drop-down) than safari from TFA. I find FF to be the best usability-wise
    - kalleboo 4y ago
      The Safari from the OP is on mobile. Chrome and Firefox on Android are arguably even worse than Mobile Safari since they don't even have the little affordance arrow https://i.imgur.com/4w8IvO8.png https://i.imgur.com/4w8IvO8.png Safari on desktop is pretty bad but at least it leaves the text fields there for you to just type in https://i.imgur.com/NSRvPcm.png https://i.imgur.com/NSRvPcm.png
      - culi 4y ago
michaelteter 4y ago
> Actually the Firefox and Chrome date pickers look... exactly the same It does not seem that most websites use the built-in date pickers. I've seen dozens of different date pickers all while using Firefox. This is the key problem. At least if everyone used the browser native date picker, it would be consistent within that browser. Then we could debate about which browser had the better one (and maybe standardize).
ls15 4y ago
Or 1959-12-31, so nobody has to guess if it is yyyy-MM-dd or yyyy-dd-MM

by culi 4y ago

RussianCow 4y ago

> 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.

Someone1234 4y ago

> Actually the Firefox and Chrome date pickers look... exactly the same They look nothing alike though. Are you trying all three on iOS? On iOS Apple only allows a single rendering engine (WebKit), so Apple dictates what the <input type="date" /> entry dialog looks like, and there's nothing other "browsers" on the platform can do to fix it (since they're just shells built on top of WebKit).

culi 4y ago
Hmm I'm on a macbook. I assumed the component was a browser implementation, but maybe MacOS somehow overrides that? Would you mind providing a screenshot of how it looks on a different OS? Edit: I've google around and I'm only finding UI that looks the same so now I'm very curious about what UI you're seeing that looks different. What browser and OS are you on if you don't mind me asking?
- deleted 4y ago
  [deleted]
- Semaphor 4y ago
  Windows: Firefox https://i.imgur.com/j8djrhN.png https://i.imgur.com/j8djrhN.png Chrome https://i.imgur.com/mmBInsQ.png https://i.imgur.com/mmBInsQ.png Both different, both slightly better (because it's clearer the year field is a drop-down) than safari from TFA. I find FF to be the best usability-wise
  - kalleboo 4y ago
    The Safari from the OP is on mobile. Chrome and Firefox on Android are arguably even worse than Mobile Safari since they don't even have the little affordance arrow https://i.imgur.com/4w8IvO8.png https://i.imgur.com/4w8IvO8.png Safari on desktop is pretty bad but at least it leaves the text fields there for you to just type in https://i.imgur.com/NSRvPcm.png https://i.imgur.com/NSRvPcm.png
    - culi 4y ago

michaelteter 4y ago

> Actually the Firefox and Chrome date pickers look... exactly the same It does not seem that most websites use the built-in date pickers. I've seen dozens of different date pickers all while using Firefox. This is the key problem. At least if everyone used the browser native date picker, it would be consistent within that browser. Then we could debate about which browser had the better one (and maybe standardize).

ls15 4y ago

Or 1959-12-31, so nobody has to guess if it is yyyy-MM-dd or yyyy-dd-MM