[Accessibility] tabBarExtraContent is owned by role="tablist"

Summary

tabBarExtraContent is rendered inside the element with role="tablist". When the extra content is interactive, the tablist therefore owns a non-tab control and axe reports a critical aria-required-children violation.

This is the canonical implementation behind these accepted Ant Design reports:

• https://github.com/ant-design/ant-design/issues/49502
• https://github.com/ant-design/ant-design/issues/53584

Minimal reproduction

<Tabs
  items={[{ key: 'one', label: 'One', children: 'Panel one' }]}
  tabBarExtraContent={<button type="button">Extra action</button>}
/>

Run axe with the aria-required-children rule enabled.

A focused probe through current Ant Design master, which uses @rc-component/tabs 1.12.0, produced this reduced structure:

<div role="tablist" aria-orientation="horizontal" class="ant-tabs-nav">
  <div class="ant-tabs-nav-wrap">
    <div class="ant-tabs-nav-list">
      <div role="tab">One</div>
    </div>
  </div>
  <div class="ant-tabs-extra-content">
    <button type="button">Extra action</button>
  </div>
</div>

Observed axe result:

aria-required-children (critical)
Element has children which are not allowed: button
Target: .ant-tabs-nav
Related node: .ant-tabs-extra-content > button

The canonical source has the same structure on current master (bf6dbda):

• TabNavList/index.tsx puts both ExtraContent positions, the tab nodes, the add control, and OperationNode under the element with role="tablist".
• ExtraContent.tsx renders the caller-provided content inside that tree.

Expected behavior

The tablist should own the role="tab" elements, while arbitrary interactive extra content remains visually adjacent but outside the tablist's accessibility ownership.

Possible implementation and regression boundaries

One possible direction is to put role="tablist" on an inner element that owns only the tabs, while leaving extra content and other non-tab controls outside it. The exact DOM change needs to preserve the existing tabListRef measurements, scrolling, overflow dropdown, ink bar, and layout behavior.

Regression coverage should include:

• interactive extra content at both left and right positions;
• editable add/remove controls and the overflow/more operation;
• horizontal, vertical, and RTL layouts;
• existing keyboard navigation and tab measurement/overflow tests;
• an axe assertion with aria-required-children enabled.

I searched the canonical repository's open and closed issues and PRs and found no duplicate for extra content under the tablist. #809 is related accessibility work, but it concerns the remove button's own role rather than tabBarExtraContent ownership.

AI assistance disclosure: Codex was used to trace canonical ownership, search existing issues and PRs, and run the focused axe reproduction. The reported DOM and axe output were verified against current source.

Start in src/TabNavList/index.tsx, especially the tablist wrapper and its placement of ExtraContent, operation controls, and tab nodes; then read src/TabNavList/ExtraContent.tsx. Run the focused axe reproduction with aria-required-children enabled and inspect existing keyboard, measurement, overflow, layout, and RTL tests. Done means extra interactive content is outside tablist ownership without breaking refs, scrolling, overflow, ink-bar behavior, or keyboard navigation.