Interest in prototyping datepicker with airbnb/react-dates #980
-
SendGrid is re-building part of our stats infrastructure and I'll be looking at updating and we'll be updating some of our datepickers with react-dates and probably update our styles from ui-components. Is there any interest to provide the CR we use as a building block/prototype for the upcoming paste datepicker? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
So, there are some constraints that we have as a system that will likely mean we won't be using react-dates as the basis of our date picker. AccessibilityFirstly, accessibility. It isn't very accessible. I can see that they've had a go trying to make it usage, but it isn't very good from an experience perspective. The communication of important information just isn't up to the standard that we expect and it doesn't follow the ARIA Authoring practices guidelines. As you can see from the exposed accessibility tree, they basically try to fake it and describe it well (Application, generic, generic, button with a lot of descriptive text) Rather than expose the correct information via machine readable APIs (Dialog, Grid, Row, selected Cell, etc) https://w3c.github.io/aria-practices/examples/combobox/combobox-datepicker.html Styling APIsWith the upcoming support for a Customization Provider from Paste, it requires us to only use 3rd party libraries that allow us to provide all visible UI via Box and Text primitives, not via classnames and CSS. From memory react-dates provides a lot of out of the box UI that you can only override with a custom stylesheet, and that likely won't suit our needs for support customers using Flex and future programmable UIs. DesignI also don't know from a Product Design perspective whether react-dates would suit our needs either. There are a number of ways that you can display and communicate dates and ranges, and I feel like we'd need to do a pretty big deep dive into the PD requirements before we commit to any library, as the APIs might significantly change. With all that said, we'd of course be interested to see how you approach it, I'm just not sure how usable it would be for the system. Just wanted to give the full constraints out first, without really saying yes or no. |
Beta Was this translation helpful? Give feedback.
So, there are some constraints that we have as a system that will likely mean we won't be using react-dates as the basis of our date picker.
Accessibility
Firstly, accessibility. It isn't very accessible. I can see that they've had a go trying to make it usage, but it isn't very good from an experience perspective. The communication of important information just isn't up to the standard that we expect and it doesn't follow the ARIA Authoring practices guidelines.
As you can see from the exposed accessibility tree, they basically try to fake it and describe it well (Application, generic, generic, button with a lot of descriptive text)
Rather than expose the correct information via machine…