[Feature Request]: Add dismissibility to single tab

[phooning]

The problem

If <Tabs dismissible> is applied, all Tabs have the close button displayed. There is no way to remove the close button on an individual tab.

The solution

A tab should have its own dismissible prop, or a solution that leads to specifying undismissible or tabs without the close icon. An example solution might be

<Tabs dismissible>
  <Tab dismissible={false}>
    {content}
  </Tab>
</Tabs>

Which could be conditioned to render the close button in the Carbon Tab component: https://github.com/carbon-design-system/carbon/blob/main/packages/react/src/components/Tabs/Tabs.tsx#L1446

Examples

This example exists hierarchically in popular applications. For example, in Google Drive, nested folders and its details will open up on the path tabs, which will have different actions (like delete), but the main (first) folder "My Drive" will never have that action.

Application/PAL

IBM DataPower Gateway UI

Business priority

Medium Priority = upcoming release but is not pressing

Available extra resources

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

Thank you for submitting a feature request. Your proposal is open and will soon be triaged by the Carbon team.

If your proposal is accepted and the Carbon team has bandwidth they will take on the issue, or else request you or other volunteers from the community to work on this issue.

[tay1orjones]

Thanks for opening up this request! This was an intentional decision made when the design spec for dismissible tabs was researched and defined, ultimately delivered in #13529

If I'm remembering right, it was grounded in supporting consistency of users' mental model across all the tabs. Mixing dismissible and non-dismissible is prone to confuse users both sighted and non-sighted. Having them all the same ensures consistent keyboard focus and interaction as well as visual and structural cohesion.

That's not to say we can't do this request - just something to consider. @kingtraceyj @laurenmrice what are your thoughts?

[tay1orjones]

@mbgower I remember these tabs enhancements being particularly finicky to get right accessibility-wise. Do you have any thoughts on this?

[mbgower]

@tay1orjones, this closed issue for tablist supporting children seems to outline an approach that had support from aria WG, and is supported with current technology. If you read through to the end, they added in aria-actions as a future-proof method.

Basically, if the currently selected tab has a child button, it will end up as the next item in the tab order. If it doesn't a tab will just proceed to the tabpanel.

I'm cc'ing @tombrunet on this, in case he has any input on what they outline.