Internationalization of accessibility properties from getDateProps

[adroste]

The following line returns an aria-label in an english american format.

https://github.com/deseretdigital/dayzed/blob/40d0161ee212891b5d0ca8834e372f29fbbe6b5b/src/dayzed.js#L32

This does not seems right in the context of internationalization. In fact, the w3 aria datepicker example (see: https://w3c.github.io/aria-practices/examples/combobox/combobox-datepicker.html) shows a slightly different usage with a table with a 'grid' role and custom 'data-date' attributes.

What is the intended way to cope with a11y and i18n?

[ApplyBoardDak]

@adroste it seems like this project isn't really maintained anymore as there's been very few changes over the past 2 years. have you considered an alternative at this point?

[arthurdenner]

The library provides many building blocks to calendars and datepickers so the consumer has total control over rendering.

All functions from dayzed forward properties to the underlying components, so you can override the aria-label and all other properties by just providing them to getDateProps and other functions.

Regarding maintenance, from my perspective as a long-time user of the library, the library is in a "pretty much done" state. As mentioned, it provides building blocks and allows for overrides, we (consumers) build on top of it.

[ApplyBoardDak]

thanks for the response @arthurdenner – it might be worth mentioning in the README that this library is feature-complete and that it might only be maintained to support new versions of React + security patches. I say this because I'm currently evaluating datepicker libraries for a design system and was skeptical of Dayzed because of this "lack of maintenance", even though that's not really the case.