RAC - Why filter out role and aria-roledescription on the Tabs element?

[JNaftali]

I'm using RAC's Tabs component to create a basic carousel. First of all: y'all did an absolutely killer job with RAC. Being able to e.g. add additional controls without being forced to drill all the way down to the useTabList hooks is very nice.

The only time I found myself puzzled about RAC's choices was in trying to add a few aria properties as recommended in the w3c carousel pattern guide. Relevant excerpt:

• A carousel container element that encompasses all components of the carousel, including both carousel controls and slides, has either role region or role group. [...]
• The carousel container has the aria-roledescription property set to carousel.

So I thought, the div rendered by Tabs doesn't have any aria markup - shouldn't cause any trouble to add those. Except Tabs filters out those props instead of passing them along to the div!

Easy enough to work around (just rendered my own div and set the props on there) but I was wondering why y'all filter those props out when you aren't trying to set them yourselves?

[snowystinger]

Tabs implement this pattern https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
Not the carousel pattern. I can kinda see that it might be enticing to make a Carousel by wrapping a Tabs component along with prev/next buttons, but I'd double check the guide on roles and attributes, and also the overall experience differences between using it the more prescribed way vs trying to make Tabs into something it isn't intended to be.

https://www.w3.org/WAI/ARIA/apg/patterns/carousel/#roles_states_properties
https://www.w3.org/WAI/ARIA/apg/patterns/tabs/#roles_states_properties

For instance, it suggests for Carousel

Each slide container has role group with the property aria-roledescription set to slide.

vs Tabs

Each element that contains the content panel for a tab has role tabpanel.

Usually when we prevent certain attributes it's because they have the ability to break the pattern we've implemented. I haven't checked what would happen in this particular case though, as we didn't write Tabs with Carousel in mind.

[JNaftali]

The carousel pattern guide offers 3 different ways to implement a carousel. One of them is "Tabbed Carousel Elements," which says (among other things):

Each slide container has role tabpanel in lieu of group, and it does not have the aria-roledescription property.

So it seems pretty explicit that they had in mind that carousels could be tabs with some extra bits. I don't know anything about screen reader/browser support for that bit of the spec (if you do I'd love to know!), but it is in there.

[snowystinger]

You are correct. I totally missed that. My bad. I'll have to look at that more closely.

[snowystinger]

I had a chance to look this over again today

A carousel container element that encompasses all components of the carousel, including both carousel controls and slides, has either role region or role group. [...]
The carousel container has the aria-roledescription property set to carousel.

Our stance on this would be what you are already doing, to use a wrapping div which is the region/group. Tabs was built to be tabs, not a carousel, even if a carousel can be implemented using tabs.

This particular instance seems fairly innocuous, and maybe we could consider allowing some other dom props through, however, if the tabs pattern is ever updated and that element is used, it'd be harder for us to update without breaking changes. Likewise, if the carousel pattern was ever updated, we'd need to compensate for that possibly or make the pass through of props extremely permissive. I think composition is a fine pattern to employ here to give us the flexibility we need and the functionality you need.

Thanks for the discussion on this, I think it might be worth considering adding a Carousel RAC component. Sounds like we're most of the way there :)
Let us know if you have any other questions.

[JNaftali]

I hadn't thought of the patterns as things that change, but of course they would - obvious now that you say it. Makes sense to leave space for that. Thanks for the explanation!

My 2 cents, there's a whole lot of functionality to a carousel (depending of course on what people mean by "carousel") that has nothing to do with accessibility and I wouldn't blame y'all if you didn't wanna touch that with a 10 foot pole. Might be easier to just add an example to the Tabs docs showing how to wrap the component for use as a carousel.

[mryechkin]

I think it might be worth considering adding a Carousel RAC component

That would be most incredible 🙏 I've asked about it on several occasions in the past, and it seemed like the general response from the team was that there weren't any plans for it. However I think it would make for a valuable addition, as there aren't really any viable good options for a headless carousel out there.

[mryechkin]

@JNaftali any chance you could share how you've implemented this? My team will have a need for a Carousel component in our library in the future, and I'm dreading the day we have to build it. Trying to avoid having to install additional 3rd party libraries, so I'm curious how you implemented it with the RAC Tabs?

[JNaftali]

It's just a normal tabs setup with the TabList at the bottom (and styled to look like dots) and extra controls as seen in TabbedNavigation from this example in the react-aria docs. The only real addition a11y-wise was an extra wrapper div with role="group", aria-roledescription="carousel", and an aria-label that satisfies the third bullet point in the pattern docs for a basic carousel - everything else was just giving good labels for the components that react-aria gives you