Use react-aria for accessibility?

[devongovett]

Would be awesome if nextui used react-aria under the hood to ensure all components are accessible. It is a library of hooks designed to be used by this exact kind of library. It only provides behaviors and a11y, no rendering, and is fully customizable. I'm obviously biased as one of the maintainers, but I think it will save you a lot of time implementing complex behaviors from scratch, and testing them across many different devices (i.e. mouse, touch, keyboard, etc.) and assistive technologies.

I took a look at the existing components and found many accessibility issues with them (can go into detail if you want). I think React Aria could help with this, and let you focus on what's unique to this library rather than reinventing everything from scratch. In my experience, it is also waaaaaay easier to build accessibility in from the start than try to add it later.

Anyway, this is just a friendly message. Feel free to reach out if you have any questions. 😄

[hmbrg]

Radix Primitives seems to be the more modern alternative, and it's build by the Stitches team (which NextUI uses under the hood already).

For now, react-aria provides some functionality that Radix Primitives doesn't (like a combo-box or autocomplete) but the devs are saying this is coming soon to.

[devongovett]

Modern? Both are very actively developed and released around the same time haha. 😉

Again, I'm biased and both are good choices and better than rolling your own, but in my opinion here are the advantages of React Aria:

1. Better touch support. I think Radix hasn't really focused on it. For example, see our series of blog posts about the humble button. It's way harder than it seems.
2. Hooks based. Lower level, but this offers more customization options which can be especially useful for libraries. Radix could be built on top of React Aria if they chose to.
3. Extensively tested. I'm not sure of the level of testing, and on which devices Radix is tested on. React Aria places a huge emphasis on this, and deals with tons of edge cases across many different screen readers and devices. The blog post about combobox goes into this more.
4. Internationalization support. We have translations for accessibility messages in 30+ languages, plus have support for RTL, many number and calendar systems, etc. Again, much easier to start with this than to add it later. An example is our number field.

[hmbrg]

You've made some very good points here. I've used both libraries in the past and to me, react-aria's hook API is less intuitive than Radix's component based approach. That being said, I totally agree with you that react-aria is the more feature complete and polished version that offers more customization than Radix. Considering that NextUI is a library that would abstract away react-aria's API into a component based approach, I think I agree with you that react-aria might be the better fit for this project.

Oh, and personally, your reply has been a small lesson for me to not always just believe the twitter hype and to compare libraries like these thoroughly by myself. Thanks for that! 🙂

[jrgarciadev]

Hey @devongovett I'm really glad to have you here, thank you so much for the detailed suggestion we are evaluating both options react-aria and radix-ui (both are amazing libraries 🚀) in detail to see which is better suited with the current implementation and which one impact the final bundle size less. Could you please join the NextUI discord server in order to clear related questions?

Invitation -> https://discord.com/invite/9b6yyZKmH4

Thanks 🙏🏻

[devongovett]

No problem. I joined. Feel free to message me with any questions you have.

[DaniAcu]

I think that adding any of this library will increase the bundle size of next-ui a lot. If we want to track accessibility I recommend using react-aria instead of radix.

However, I think that we need to refactor this code a lot for adding react-aria and we are facing the problem of sacrificing performance to add this accessibility library, which is incongruence because we are reducing the access to the sites when don't have internet or resources (performant devices) to access.

If you could be able to share with us the accessibility issues that you found, it will be really helpful to start working on fixing them.

[devongovett]

Bundle size is certainly an area where we would like to improve. Perhaps as a project with a strong focus on that, Next UI could help us out in that area or point out areas we can make better.

A couple points about this:

1. I don't think trading off accessibility and user interactions in favor of bundle size is the right approach. We need to have both. This kind of stuff does require a fair bit of code to implement right, so there will be some cost, it's just a matter of minimizing it. For example, React Aria is fully tree-shakeable so you only get what is needed. We can certainly find areas to improve, but I think it's worth acknowledging that there will be some cost to having good accessibility. I think it is important to balance both loading time and UX, and as you mention, they are related in many ways.

2. Implementing all of this yourself is an absolutely monumental task, as I've learned from experience the last few years. Most of the components in Next UI so far are fairly simple from an a11y perspective (except maybe Modals), and you could probably do a good job without any libraries. I would be more worried about the upcoming components you have planned, like autocomplete, dropdown, table, etc. These are quite challenging to get right. For example, we spent almost a year developing and testing our combobox (autocomplete) to make sure it worked on every device and with all assistive technologies. See our blog post for details about this.

   The main purpose of React Aria is to make this easier for developers building UI libraries like yours, and to help centralize the implementation of these accessibility details in one place. Collaboration on the low level details improves a11y for all. Unless you are willing to make this kind of time commitment to ensure your implementation works on all devices and for all users, it would be expedient to work together on details like this, and allow Next UI to focus on its core differentiators. Since you can adopt React Aria on a component-by-component basis, I think it should be easy to use where you can and not where you don't need it.

I am hopeful that we can work together to improve UI development for all, rather than continually reinventing the wheel. If you have suggestions on how to improve React Aria to work for your use cases, please let us know and we are happy to collaborate on it!

[jrgarciadev]

You have good points here, after we analyze the impact of adding react-aria in terms of performance/bundle size vs the effort of making fully accessible components, we decided to add react-aria to reduce the time we spend building the components and contribute to making an accessible web.

The implementation will be incrementally starting with the interactions package then the Button and so on, thank you for your clear explanations, happy to collaborate on it with you!

[devongovett]

Happy to hear that. Please don't hesitate to send me messages if you run into any issues. I'll be happy to help!