Skip to content

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

Description

@nrps9909

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions