Comparing 3 React Accordion Libraries

June 19, 2022 - 6 minutes

Recently for my job, I had to create a set of React components to implement an accordion for our project. While one of the options was to implement everything from scratch, the alternative was to look into existing component libraries and make use of those.

At first, it didn’t really feel necessary to involve a third-party library in this task. How difficult could it be to implement an accordion myself? It just needs a clickable header, content that can be toggled using the header, and it should be possible to have multiple groups. However, just to be sure, I dove into several libraries to see what they were up to.

In the end, we opted into using one of those libraries. However, the path that led to that decision was quite interesting. In particular, it was fascinating to see the similarities and differences between these third-party libraries. I went through multiple libraries, made a thorough comparison, and proposed it to the team.

While the result isn’t necessarily interesting, I think the comparison itself can be useful and educational for certain React developers. Therefore, we’ll look into that comparison, the requirements that I had to fulfil, and all the different factors that were relevant in this comparison.


Obviously, there were several requirements for the accordion that I had to implement.

  • Since I was going to use a library, I had to be careful of its bundle size. While there was no specific size limit, it still makes sense to keep this to a reasonable number. There’s no reason to include an extremely bloated library just for an accordion, but it’s also counterproductive to use an extremely small library where desired features are missing and thus need to be implemented ourselves.
  • Due to the composable nature of our code base, we wanted a library that would allow us to implement an accordion in that style. Instead of one big component that would configure everything, we wanted a set of composable React components. This would allow for the highest flexibility and adjustability long term.
  • While we weren’t planning on adding extremely fancy animations to the accordion, some simple animations for the closing and opening of the accordion groups were desired by design.
  • While accessibility features are definitely important, the priority on those wasn’t high in this story. Being able to trivially implement them in the future would be great, but right now the only accessibility-related requirement is that it should be controllable for keyboard users.

The Libraries

In the end, the most promising libraries boiled down to the following 3, rc-collapse, react-collapsible, and react-accessible-accordion. These were found at the NPM registry and were chosen based on their activity, popularity, degree of integration with React and TypeScript, and documentation. In this section, we’ll take a deep look into all of them.


By far the most popular library in this comparison of the three is rc-collapse. On the NPM registry, the library clocks in an astonishing amount of weekly downloads of more than 840k. The size of the library is 46.4kB according to NPM, 21kB minified, and 7.2kB gzipped according to Bundlephobia.

However, the components of the library weren’t extremely optimized for a composable structure. While there are components for the container and the groups, which accept components as their children, configuring the header has to be done through these group components as a prop.

Animations are quite straightforward to implement using this library. Under the hood, the accordion group components make use of the rc-motion library. This provides a lot of options to configure the animation and abstracts a lot of the manual CSS work away for the developer.

The biggest drawback of this library is the limited number of accessibility features. According to the W3C standards, there are quite some aspects to a fully accessible accordion. From those, rc-collapse has the least of them implemented compared to the other libraries in this comparison. Basically, the only one they have implemented is aria-expanded for the accordion groups, which is relevant for screenreaders.


The least popular and updated library of the three we’re considering here is react-collapsible. It has the fewest weekly downloads, slightly below 100k, and hasn’t received any updates in 8 months. Size-wise, NPM reports a similar size to the previous library of 43kB, while Bundlephobia says it’s on the smaller size, namely 10.3kB minified and 3.3kB gzipped.

Similar to rc-collapse, the composability of this library is on the limited side. The accordion group contents are specified through the component’s children, but the header is once again specified through a prop. This makes it suffer from the same issues regarding composability.

For animations, there are some options available for configurations. Although these are not extremely elaborate, there seems to be a built-in option for height animation. As this was our main requirement in this aspect, the limitations can be overlooked.

This library has a relatively decent number of accessibility features implemented. Not only does it have aria-expanded, but it also has the larger family of aria attributes implemented in the form of aria-disabled, aria-controls, and aria-labelledby. Besides that, it also implements the tabIndex and role attributes, which are relevant for screenreaders and keyboard control.

For this library, there were 2 downsides I came across. First of all, I couldn’t get their example project running. This is quite a minor downside, but it made it more difficult for me to grasp how their component looks, feels, and works.

The other and more significant downside is that the library’s component is only responsible for rendering one group. Since there is no encapsulating component for the entire thing, this makes it slightly inconvenient for implementing an accordion. In particular, getting accessibility features and proper keyboard controls across the different groups will require quite some manual work due to its separation.


By far the largest library in this comparison is react-accessible-accordion. According to NPM, it ships with 100kB of assets, while minified and gzipped it ships with 13.6kB and 4.1kB respectively according to Bundlephobia. If the latter two don’t apply to you, then you have to settle for double the size compared to the other libraries. This can be quite a significant hurdle, even if it’s only about 50kB.

One of the major advantages is the composable nature of the library components. Basically, the library already provides a collection of composable components out of the box to construct an accordion. This matches perfectly with our requirements, as it allows me to reuse them one-to-one. The only thing I need to implement is wrappers around those components based on the API that we want to expose in our codebase.

The other big benefit to this library is the number of accessibility features provided out-of-the-box. Compared to the other libraries, react-accessible-accordion has implemented them most elaborately and diligently. It contains proper roles, labels, the family of aria attributes, keyboard controllability, and the aria-level attribute.

The main drawback of this library is its lack of animation support. While the other libraries allow you to configure the animation for toggling the accordion items, this library doesn’t provide any feature like that. The only example of animation they provide is related to opacity, which isn’t relevant to us. Therefore, animations for toggling visibility and height would have to be implemented ourselves, which isn’t always trivial.

Final Thoughts

In the world of JavaScript development, it’s not uncommon to reach out to a third-party library. However, there is an enormous amount of them and all with varying degrees of quality and features. Because of that, it’s easy to get lost in deciding which library to use.

Therefore, this article went over such a scenario deciding between 3 different libraries for implementing an accordion. While the result isn’t the most important part, the comparison itself is more interesting and educational. It dives into the requirements, the different aspects to consider for libraries, and how to bring it all together.

While the result isn’t necessarily interesting, I think the comparison itself can be useful and educational for certain React developers. Therefore, we’ll look into that comparison, the requirements that I had to fulfil, and all the different factors that were relevant in this comparison.

After graduation, my career is entirely centered around learning and improving as a developer. I’ve began working full time as a React developer and I’ll be blogging about everything that I encounter and learn during this journey. This will range from improving communicational skills in a technical environment, becoming a better developer, improving technical skills in React and JavaScript, and discussing career related topics. In all of my posts, the focus will be on my personal experiences, learnings, difficulties, solutions (if present), and also flaws.

If you’re either interested in these topics, more personalised technical stories, or the perspective of a learning developer, you can follow me either on Twitter or at Dev to stay up to date with my blogposts. I’m always learning, so stay tuned for more stories! 🎉