> Unfortunately it doesn't seem to have a way to jump to a specific year
Which is a showstopper in my opinion. Dates in the past beyond the current year are common, e.g. for birthdays. Even for e.g. a meeting scheduling app, this is too great a limitation because if other functionality is added later, the dev will then have to choose between two separate date pickers or replacing this one anyway.
Otherwise, it is very nice and it would be a top choice for me.
The aim is not to give you a full date picker, instead only the lower-level building blocks that allow you to build your own. You likely already have your own inputs, buttons, popover etc components. So why not use them?
Even still, choosing the year is a functionality issue (and potentially a UX issue), not a UI issue that is addressed by using one's own inputs, buttons, etc.
I work on a design system and I'm responsible for the DateInput / DateRangeInput component.
Jumping to a specific year is a bit of a painpoint for me.
My component is composed of a text field that accepts dates in many formats. On focus it displays a dropdown with a calendar very similar to Cally (including the next/previous month buttons). As user enters a date in the input field, the calendar updates. The user can also use the calendar to pick a date in the same way as Cally, which updates the input field.
My argument for this being fine is that when a user is entering a date far in the past (or future), such as the date of birth – surely they prefer to enter it in the input field via keyboard, instead of clicking all around the calendar dropdown. Alternatively, perhaps an entirely different component should be used in that use case – perhaps a set of three text fields (limited to numbers).
I semi-regularly get feedback from the business analysts that they would like to have a way to choose the year in the calendar dropdown, but I'm not entirely sure what would be the best way to enable that.
Sorry I'm late. Author here. Yeah this is a limitation right now. For dates of birth and other hard/known dates, I would never recommend a date picker.
Though I will likely never offer this functionality directly in the components themselves (per the docs: they are not meant to be a complete solution for date pickers, only the lower level parts that are hard to get right). But rather I'll open up the API to allow people to build this stuff themselves. I imagine I'll get this done in the next few days
Choosing the year is a functionality issue (and potentially a UX issue) that is hard too get right. It is not a UI issue that is addressed by using one's own input controls.
Accessible? Great! How does this integrate with Dragon or any other speech recognition accessibility aid?
(Yes I'm being snarky/bitter most UI designers seem to assume everyone's hands either work perfectly or not at all (i.e. using mouse or a unicorn stick). Joys of being in the forgotten middle)
Hey author here. You're right, the accessibility part is very much focused on screen readers. I would love to improve support for other input methods. If you have any feedback, I'd very much appreciate it.
Andoid itself is a barrier. They are trying to catch up to iOS accessibility since what, 15 years now? And after all that time, its still 80/20 iOS/Android when it comes to users requiring a screen reader.
when it comes to browsers, I found Android way better with respect to accessibility due to Safari lacking recent web standards support, though my perspective is of someone testing a11y, not depending on it.
for mobile browsers, I noticed tab order, tab focus-active paeudostate, and focus fallback (eg what gets focused when a menu closes) to behave differently /incorrectly compared to desktop browser. Also aria-live often does not work on mobile.
Unfortunately it doesn't seem to have a way to jump to a specific year