[RFC] Find popper.js alternative to create accessible Storybook UI dropdown components #22415
Replies: 13 comments 21 replies
-
Thank you very much for your RFC. Much appreciated! Currently, I see the following (potential) issues with introducing Reach UI:
I think the main issue currently is that we are not using popper.js in an accessible way. We should spawn the menu elements next to the button/element which triggers the menu opening. Currently, that's not the case, and the elements are placed at the |
Beta Was this translation helpful? Give feedback.
-
Thank you both, @valentinpalkovic and @JReinhold! I have re-purposed the RFC based on your comments. I will check the UI libraries mentioned here, and leave my findings in this RFC taking into account:
Any other points you consider worth taking into account? |
Beta Was this translation helpful? Give feedback.
-
Hi, there! After carefully reviewing each of these libraries, testing them out, and checking the existing Storybook codebase and how the components have been crafted, I have reached the following conclusion: React Aria would fit best with the existing codebase, as it just provides the behavior and accessibility through React hooks that we can apply to any component, perhaps having to, at most, extend a couple of prop types for some of them, or creating a wrapper for avoiding this prop extension, for example. Here's an overview of React Aria:
What are your thoughts on this? |
Beta Was this translation helpful? Give feedback.
-
Hi @danielmarcano, Thank you so much for wrapping this up. I wonder whether you could create a kind of comparison table to understand why react-aria was chosen and why, e.g., Radix UI wasn't. I am also wondering whether you took https://floating-ui.com/ into account since it is the accessible derivative of popper.js. Since we haven't decided yet, whether other components should be replaced by premade accessible ones as well, a quick win could be achieved by using floating-ui without introducing potential disruptive changes. I can't wait to hear your answer :) |
Beta Was this translation helpful? Give feedback.
-
Hi @valentinpalkovic, thank you for bringing Floating UI into the table. I had not considered it, but I have now taken a good look at it. As for Radix UI and React Aria, being fully honest, I had gone through the docs of both of them, but had not tested them out to see which API was easier to work with, or felt more friendly and flexible. So I decided to prepare a small codesandbox testing both Radix UI and React Aria, which has actually changed my mind on both libraries. Radix UI felt a bit nicer to work with. For some reason, while going through its docs, I thought it was less flexible in terms of styling, but it actually allow us to "add styles with our preferred CSS technology", as noted by their documentation. As for React Aria, it's evidenced in the codesandbox that it requires a lot more "setup" and boilerplate in general than Radix UI, and it seems like the "dependency" between react-aria and react-stately would be a bit tricky to replicate with a different library (other than react-stately), or with custom code written from scratch, which seems a bit much. I have also checked Floating UI, and will link a codesandbox taken from their documentation. It definitely looks better than popper.js, and has been built with accessibility in mind, although from the codesandbox we can tell that its integration requires a lot of manual work and boilerplate. Its API also looks more complex than React Aria's one, which makes me think it might not be a quick win after all, but again, it's all open to discussion, of course. If you could check the codesandboxes and let me know what your thoughts are, that would be awesome! |
Beta Was this translation helpful? Give feedback.
-
For the sake of consistency, here's the information of both Radix UI and Floating UI: Radix UI:
Floating UI:
|
Beta Was this translation helpful? Give feedback.
-
Hi there, @valentinpalkovic @JReinhold, hope you are doing great! Have you been able to go through the latest messages / have some more thoughts? |
Beta Was this translation helpful? Give feedback.
-
Hi @danielmarcano, sorry for the late reply, but I was on vacation :) Thank you very much for your detailed analysis. This is very helpful and should make decision-making easier. As far as I can tell, even Radix UI uses Popper.JS in the background. I now have a question, however, that the @storybookjs/core maintainers will have to answer in a closed manner: Do we now want to make only the dropdown elements accessible, or do we have as a goal to replace more components with Radix UI components? If we only want to make the dropdown elements accessible, integrating Floating UI would be easier since a) there is a migration guide from Popper.js to Floating UI, and b) we would probably not cause a breaking change by doing so. In the long run, it would probably make sense to rely on a library like Radix UI, since we can then handle the accessibility issue uniformly with one library. Based on your analysis, I would personally lean towards using Radix UI. Would you be willing to work on this topic and create a PR with the needed refactorings, should the team decide to go with this solution? |
Beta Was this translation helpful? Give feedback.
-
There is Headless UI and Headless UI Float. The former is from the authors of TailwindCSS and the later is a community made thin wrapper that uses Floating UI under the hood. After migrating two projects, I can tell that they barely cost anything to adopt as long as you are not trying to over engineer your components, like creating a component that is too generic. Headless UI is opinionated in term of accessibility though, and the programatic support is this in progress (calling |
Beta Was this translation helpful? Give feedback.
-
Sorry for being away from this for a long time, thanks for your hard work and research @danielmarcano. I agree with @valentinpalkovic, the conclusion to this RFC from the core team: Introduce Radix UI to the components.
🚀 |
Beta Was this translation helpful? Give feedback.
-
Hi @danielmarcano 👋, I'm just catching up on your RFC. Fantastic job. Thanks a lot 🙏. We are in the process of improving our UI components for the exact reasons you mentioned but also to make sure it's coherent with the design we would like to implement. I'm part of the design team and I'm working on a new UI library that will allow us to shape an entirely new set of UI components for Storybook. I would love to share it with you and hopefully we can collaborate together on it if you're interested. I'm writing a new RFC for this new library. As soon as it's ready I'll cross share here to get your eyes on it. |
Beta Was this translation helpful? Give feedback.
-
I've been exploring Radix since we are using it in other places like on our Marketing site. Here's a draft PR for new form components I'm working on - #23469. I used Radix on the new This component is heavily inspired from the Select component on Shadcn (https://ui.shadcn.com/docs/components/select). I need to test it a bit more but so far it is working pretty well with all accessibility in mind. |
Beta Was this translation helpful? Give feedback.
-
Hi everyone! I have just had an onboarding with @cdedreuille, and will begin working on the creation of the DropdownMenu for the new experimental UI package. Such component would be the beginning of this RFC's outcome. Also, could we update the status of this RFC and leave it as "accepted" (I'm guessing this is done with a label), as mentioned in the docs? |
Beta Was this translation helpful? Give feedback.
-
Status: accepted; championed by @valentinpalkovic
Summary
Finding an alternative to popper.js for re-building all Storybook UI dropdowns, so that they are more accessible and keyword-navigatable.
Ideally, this would be a framework-agnostic UI components library, such as Shoelace, or a React-only library, like Radix UI or React Aria.
Credits to @MichaelArestad and @JReinhold for their suggestions.
Problem Statement
Currently, Storybook's dropdowns are not accessible via keyboard navigation, which can create barriers for users who rely on their keyboards in order to interact with / navigate through software.
As Storybook keeps growing, accessibility—a fundamental aspect in software—becomes a stronger necessity, so that everyone can have a great User Experience and take the most advantage out of the library.
All things said, there's two ways to approach this:
popper.js
)The disadvantage of the first approach being that
popper.js
is meant to be used for building tooltips, instead of dropdown menus, which means that enhancing the user-experience of the existing dropdowns requires a lot of manual work: handling keyboard events properly, taking care of any edge-cases, and being compliant with the W3C's Accessibility Guidelines.The advantage of the latter one, which is the proposed solution, is that these components will not need to be maintained—from an accessibility point of view—by the Storybook team (nor the community), so we can simply choose the UI component library that suits us best: whether a framework-agnostic one, or a React-only one.
Non-goals
Implementation
TBD
Prior Art
No response
Deliverables
Risks
Unresolved Questions
Alternatives considered / Abandoned Ideas
Adding the necessary accessibility enhancements manually, to the existing
popper.js
dropdowns. More info on this closed issue from 2020.Using Reach UI. As mentioned by @valentinpalkovic, the library is no longer being maintained. It also does not support React 18, and Storybook is on its way to support it.
Beta Was this translation helpful? Give feedback.
All reactions