3 ms·

Here's a simpler solution that's even safer for screen reader accessibility: use the platform Just set a default date and it won't default to today.

by culi 4y ago

bruce511 4y ago
When the date spans a wide possible period, like birth date, this approach doesn't solve the root problem.
- culi 4y ago
  Right, I agree. What do you think would be a better solution? The date picker in the image is basically the exact same as Firefox and Chrome's implementation minus some stylistic differences.[0] Most native components also look a lot like this. So this isn't just a Safari issue but an issue across web UI in general [0] See for yourself: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
  - masklinn 4y ago
    > What do you think would be a better solution? Better configurability which would let the author decide whether they want a calendar or a straight date input. Though I'm not sure iOS even supports a calendar-less date input anymore. This is what the "date" control looked before iOS 14: https://i.stack.imgur.com/ms5tX.png https://i.stack.imgur.com/ms5tX.png Rolling back the entire "flat" shit would probably be a good idea: before iOS 7, the control was functionally similar but had a lot more visual affordances: https://www.andyibanez.com/img/date_picker_pre_7.png https://www.andyibanez.com/img/date_picker_pre_7.png It was much clearer that the central shade is an index, and that the three fields are separate wheels. The iOS 7 picker makes it much subtler by simulating curvature, and the new sub-selector (year-month) does the same and makes the index kinda even worse by outlining it in an abstract shape: https://user-images.githubusercontent.com/6268177/209607212-4ca5bc8a-d5c3-4a9b-891f-78f4e1ed4be8.jpeg https://user-images.githubusercontent.com/6268177/209607212-...
robocat 4y ago
You think that 1/3 of user support issues due to elderly accessibility problems is acceptable? That is the context the article gave us. And in my experience for every user support issue you get, there are 100 people that had the same problem but didn’t contact user support for whatever reason. I am not suggesting my solution is perfect, but I am saying I have successfully used it (although I admit is was a few years ago now, and I first used it was when iOS and Android type=date support was unpredictably broken so type=date must not be exclusively be used). I think it was about iOS10 before the bugs in the UI to clear dates were fixed? Another situation for me was New Zealander’s confused by MM/DD/YYYY native formats when using browsers configured for US date localisation. Until April 2021, Safari on Mac didn’t even support the date control, and Safari (on Mobile or Desktop) still doesn’t support the min or max value attributes. And time entry is a complete nightmare. I always try to make sure data entry controls work well for everybody, even console devices. There are always corner cases that somewhat depend on your particular users, so compromises are necessary. Background: I have programmed HTML entry controls (combo, date, time, number, etcetera) for actual man-years of my own life. That is because I started before jQuery existed, supporting IE5.5, and the available DHTML controls were mad broken for usability. I have had to understand the compromises between different solutions on different browsers, and try to find the most elegant solution, given that data entry on browsers is an extremely gnarly problem space.
- culi 4y ago
  No tbh I actually really like your solution compared to the alternatives that have been thrown around. I'm just pointing out it's not easy to implement just to get the logic and styling to work right. And then on top of that, making sure it's screen reader and keyboard accessible adds another layer that is often simply ignored The simpler solution I put forth resolves most people's problems, maintains the advantages of using native HTML controls the way they were meant to be used, and is easy to implement in... literally a few seconds.
  - robocat 4y ago
    Totally agree. Custom entry fields have different compromises (oh defuckinently), and trying to be too tricky leads to corner-case usability problems and a heavy maintenance overhead in my experience. I judged it was worthwhile for our users’ needs at the time for me to spend very significant development time plus ongoing development time, but my choices would be totally inappropriate in many other situations.
masklinn 4y ago
> Here's a simpler solution that's even safer for screen reader accessibility: use the platform That's exactly what's happening here though, Safari shows the platform's widget. > Just set a default date and it won't default to today. That's not really helpful either, DOBs have wide ranges of dates so the need to switch year, possibly decade (as this is for the elderly) will always come up).

Here's a simpler solution that's even safer for screen reader accessibility: use the platform Just set a default date and it won't default to today.

by culi 4y ago

Here's a simpler solution that's even safer for screen reader accessibility: use the platform Just set a default date and it won't default to today.

bruce511 4y ago

When the date spans a wide possible period, like birth date, this approach doesn't solve the root problem.

culi 4y ago
Right, I agree. What do you think would be a better solution? The date picker in the image is basically the exact same as Firefox and Chrome's implementation minus some stylistic differences.[0] Most native components also look a lot like this. So this isn't just a Safari issue but an issue across web UI in general [0] See for yourself: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
- masklinn 4y ago
  > What do you think would be a better solution? Better configurability which would let the author decide whether they want a calendar or a straight date input. Though I'm not sure iOS even supports a calendar-less date input anymore. This is what the "date" control looked before iOS 14: https://i.stack.imgur.com/ms5tX.png https://i.stack.imgur.com/ms5tX.png Rolling back the entire "flat" shit would probably be a good idea: before iOS 7, the control was functionally similar but had a lot more visual affordances: https://www.andyibanez.com/img/date_picker_pre_7.png https://www.andyibanez.com/img/date_picker_pre_7.png It was much clearer that the central shade is an index, and that the three fields are separate wheels. The iOS 7 picker makes it much subtler by simulating curvature, and the new sub-selector (year-month) does the same and makes the index kinda even worse by outlining it in an abstract shape: https://user-images.githubusercontent.com/6268177/209607212-4ca5bc8a-d5c3-4a9b-891f-78f4e1ed4be8.jpeg https://user-images.githubusercontent.com/6268177/209607212-...

robocat 4y ago

You think that 1/3 of user support issues due to elderly accessibility problems is acceptable? That is the context the article gave us. And in my experience for every user support issue you get, there are 100 people that had the same problem but didn’t contact user support for whatever reason. I am not suggesting my solution is perfect, but I am saying I have successfully used it (although I admit is was a few years ago now, and I first used it was when iOS and Android type=date support was unpredictably broken so type=date must not be exclusively be used). I think it was about iOS10 before the bugs in the UI to clear dates were fixed? Another situation for me was New Zealander’s confused by MM/DD/YYYY native formats when using browsers configured for US date localisation. Until April 2021, Safari on Mac didn’t even support the date control, and Safari (on Mobile or Desktop) still doesn’t support the min or max value attributes. And time entry is a complete nightmare. I always try to make sure data entry controls work well for everybody, even console devices. There are always corner cases that somewhat depend on your particular users, so compromises are necessary. Background: I have programmed HTML entry controls (combo, date, time, number, etcetera) for actual man-years of my own life. That is because I started before jQuery existed, supporting IE5.5, and the available DHTML controls were mad broken for usability. I have had to understand the compromises between different solutions on different browsers, and try to find the most elegant solution, given that data entry on browsers is an extremely gnarly problem space.

culi 4y ago
No tbh I actually really like your solution compared to the alternatives that have been thrown around. I'm just pointing out it's not easy to implement just to get the logic and styling to work right. And then on top of that, making sure it's screen reader and keyboard accessible adds another layer that is often simply ignored The simpler solution I put forth resolves most people's problems, maintains the advantages of using native HTML controls the way they were meant to be used, and is easy to implement in... literally a few seconds.
- robocat 4y ago
  Totally agree. Custom entry fields have different compromises (oh defuckinently), and trying to be too tricky leads to corner-case usability problems and a heavy maintenance overhead in my experience. I judged it was worthwhile for our users’ needs at the time for me to spend very significant development time plus ongoing development time, but my choices would be totally inappropriate in many other situations.

masklinn 4y ago

> Here's a simpler solution that's even safer for screen reader accessibility: use the platform That's exactly what's happening here though, Safari shows the platform's widget. > Just set a default date and it won't default to today. That's not really helpful either, DOBs have wide ranges of dates so the need to switch year, possibly decade (as this is for the elderly) will always come up).