Hacker News Reader

Comment by ximm | Hacker News Reader

Please please please don't do this! This article doesn't even mention ARIA and the result would fail any accessibility audit.

There is really no way to implement this in JS anyway because all major browsers have native date pickers by now: https://caniuse.com/input-datetime

View on HN

<input type="datetime-local"> is tolerable for simple cases, but you can often do so much better than it: showing extra information in the pickers like disabling days that are not permitted (e.g. appointment calendar on a day nothing’s available), and allowing free-form text entry like “3pm” or “next Thursday”, those sorts of things. As it stands, <input type="datetime-local"> and its kith and kin are very restricted and mildly painful to use, by comparison. Perhaps browsers could improve them and make them more flexible and freeformable, but they haven’t done so yet. There’s a reason why very few sites actually use those date/time input types, and I don’t think it’s just their comparative recentness.

Yes, you do want to be careful about accessibility here, but it’s emphatically not a “please please please don’t do this” situation. Because its essence is just a text box, the accessibility of what’s been made here is probably actually excellent, and if it’s not, it should require only minor tweaks to make it so. You very probably actually don’t want to expose the popup in any way—for what I see, doing literally nothing for accessibility will probably be better in most instances than doing something.

> the accessibility of what’s been made here is probably actually excellent

It's not. The whole thing is in a <table>, there's no ARIA attributes let alone ones that reflect states, and the buttons are...<li>'s?

> doing literally nothing for accessibility will probably be better in most instances than doing something

This is a great example of why that's true. If the author had referenced any of the best practices for this, they wouldn't have ended up with such a bad result.

https://www.w3.org/TR/wai-aria-practices-1.2/examples/combob...

You can add stuff like that, and it’s definitely a legitimate and reasonable approach, but the popup is not functionally necessary, and done fancily even properly stands a fair chance of being just a distraction. If the popup were the only interface then yes, it would be important to optimise accessibility on it, but as it stands I think also it’s a perfectly reasonable option to make the popup entirely inaccessible by keyboard or accessibility tool, and just work with the text box. (This would be paired with things like having Up/Down work to increase/decrease the year/month/date where the cursor is, rather than Up/Down/Left/Right navigating around the calendar table.)

I’d be interested to see what a regular user of accessibility stuff would find of this stuff. I think both approaches are perfectly reasonable, with the don’t-expose-the-popup-at-all side possibly even preferable for some.

This is an unfortunately common attitude, "make the ____ entirely inaccessible by keyboard," and it leads to projects like these.

A11y and web components are well studied, start from the best practices, and if you deviate, have a good reason why that's supported by testing.

In terms of accessible date pickers, I'd refer people to the GOV.UK styleguide which explains what to use when (and by law their stuff needs to be accessible!)

https://design-system.service.gov.uk/patterns/dates/

On Linux at least, the Firefox datepicker is pretty terrible to the point of just being broken. The Chromium one is okay I guess, but with some annoyances. I don't know the status on all the other platforms, but that's why I generally just prefer controlling it myself.

Good to see Safari finally added it nine months ago. Small annoyance, but I remember the inputs' values not being consistent either. Is that still the case?

Reply on news.ycombinator.com