[Accordion] expose internal Context

[seedy]

Hello folks 👋

Background: Implementing a RadioAccordion

I recently needed to implement an Accordion where we can only open a single item at a time, with a Radio as its triggering element.

The UX expects to let user choose a configuration method between different values, then displays extra data for this configuration.

simplescreenrecorder-2022-01-21_14.57.43.mp4

I am reusing primitive components and following Radix-UI pattern to allow combining the different parts together:

I expose RadioAccordionRoot, RadioAccordionItem, RadioAccordionTrigger, RadioAccordionContent.

I decided to try combining Radio Group and Accordion primitives.

Need

Because of the implementation behind Accordion and Radio components, I needed a few suboptimal and limiting implementations:

context + controlled components

I am forced to add a layer of context providers/consumers to share information (value) between my components and enforce having controlled components

Inside my RadioAccordionTrigger, I need both current value from the AccordionItem and selected value from AccordionRoot.

It means I add 2 contexts on top of the existing ones.

To fill the selected value for AccordionRoot in my custom context, I need to have a controlled AccordionRoot component.

Do you think it would be possible to expose the components' different contexts to allow a simpler customization?

nest two buttons

Also, I notice I am nesting two button components: AccordionTrigger and RadioItem, which is invalid.

I am looking into a workaround here.

Comments welcome

Any guidance or opinion would be largely appreciated.

I am part of a team working on an open-source library: https://github.com/traefik/faency

I'm totally open to sharing ideas if they're bringing value to your awesome project.

[benoitgrelard]

Hi @seedy,

Am I understand correctly that you are using both Accordion and RadioGroup primitives together for this?
If so I believe this is wrong and this kinda highlights the point:

Also, I notice I am nesting two button components: AccordionTrigger and RadioItem, which is invalid.

I think your accordion "styling" is perfectly sensible.
However, to me, the fact that it "looks" like a radio is just that: "styling".
It has nothing to do with accessibility, and in fact, mixing both patterns will result in broken accessibility.

In my mind what this is is simply an accordion, which happens to visually style the "active" state using a design similar to a radio item.
So I think that should be purely "decoration".

Does that make sense?

[seedy]

Hi @benoitgrelard, thanks for your answer.

I think you're totally right on the implementation part. It makes a lot more sense to implement the radio part simply as a decoration.

Before validating your answer fully, I'm checking if I can only rely on the data- attributes from the Accordion to implement my visual hint.

[seedy]

Confirming, data- attributes are enough. Thanks for the quick reply 🙏

[seedy]

For anyone interested, here's the component in action => https://traefik.github.io/faency/?path=/story/components-radioaccordion--basic

[DylanVann]

I have a use case where in an Accordion.Item I would like to read if the item being rendered is open or not. In this case having access to useAccordionItemContext would make this possible.

The use case is that in these accordions there is a preview version of the content, and the actual content, and animation is done through an external library. I'd like to add aria-hidden on either the content or the preview, based on the state of the item (if it's open)