responsive tabs and maximum number of tabs

[charleneyjh1]

Hi team,

I can across a use case where I might need to use 8 tabs to show that Twilio supports multiple coding languages. I saw that the Figma component only have 7 tabs maximun, so I'm wondering if that's an API restriction?

Another issue that I came across is the spacing/responsiveness of the tabs. The current layout (1200px wide screen) can only fit 6 tabs. Is there anything we can do to try to fit more tabs in it? For example, using a dropdown to show more tabs are available when screen sizes are smaller. Is this something we can do? Any guidance would help, thanks!

[TheSisb]

Hi @charleneyjh1,

There's no API restriction on the number of tabs in code. I believe the Figma restriction was to keep designers mindful of different browser resolutions, as having too many horizontal tabs can cause a bad experience on smaller devices.

Some suggestions would be to consider using vertical tabs in your design or a Select component to make the selection more responsive friendly.

[charleneyjh1]

Thank you Shabi, I'll cut down the number of tabs.

[stern-shawn]

Hi @TheSisb ! Chiming in here since we're running into a similar issue on the new Docs platform; let me know if it'd be more reasonable to start a new discussion 🙏

We have some... not great behavior with tabs on mobile views, even with say 5 tabs and relatively short titles:

(Doc itself, these are live now thanks to Paste 🙌 )

A couple ideas we have are to make the tabs bar scrollable, similar to a pattern I found in the MUI library. I have a rudimentary version working (sans auto-scrolling as the user navigates with left/right arrow keys, etc, but the scrolling potential is there) as seen here:

scrollable-tabs.mov

We've also tossed around the notion of rendering a select/combobox component at mobile breakpoints (similar to how we're rendering a menu as opposed to the side-by-side table of contents on tablet/mobile), which I see you suggested! My question there is, how would we approach implementing that while also keeping accessibility in mind? Would it be accessible to have a structure like this, and leverage the Tabs state hook + Select events to manage which is selected?

<Tabs>
  <Select /> // Might be outside of the Tabs, ignore the bad pseudocode
  <TabPanels>
    ...
  </TabPanels>
</Tabs>

I think I understand how to do this and make it work, but I'm concerned that the pattern may not make sense to a reader, especially one using assistive technology. Any help would be much appreciated 😄

[TheSisb]

Hi @stern-shawn,

Really comprehensive question and though process. Can you make a new thread please? I don't want it to get lost in the sub-comment section of this one if possible.

[stern-shawn]

Of course, much appreciated. I've created a new discussion at #3508!