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:
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.
Summary
tabBarExtraContentis rendered inside the element withrole="tablist". When the extra content is interactive, the tablist therefore owns a non-tab control and axe reports a criticalaria-required-childrenviolation.This is the canonical implementation behind these accepted Ant Design reports:
Minimal reproduction
Run axe with the
aria-required-childrenrule enabled.A focused probe through current Ant Design master, which uses
@rc-component/tabs1.12.0, produced this reduced structure:Observed axe result:
The canonical source has the same structure on current master (
bf6dbda):TabNavList/index.tsxputs bothExtraContentpositions, the tab nodes, the add control, andOperationNodeunder the element withrole="tablist".ExtraContent.tsxrenders 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 existingtabListRefmeasurements, scrolling, overflow dropdown, ink bar, and layout behavior.Regression coverage should include:
leftandrightpositions;aria-required-childrenenabled.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
tabBarExtraContentownership.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.