Orphaned Tab Roles Audit

When an element has role="tab", screen readers announce it as part of a tab interface, for example “tab, 1 of 5”, and users expect activating it to show a panel of content on the same page. A common mistake is giving navigation links the tab role, often through a component library, so the “tab” takes the user to another page instead. Another is a tab panel that no tab controls. The page then promises assistive technology a tab interface that does not exist.

Existing checks confirm that tabs sit inside a tab list, but not that each tab has a panel. This audit reports results against WCAG 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value, on the basis that a role the element cannot live up to misinforms assistive technology.

Turning it on

This audit is experimental: it is off by default while we validate it against more real-world sites. To enable it, open a site’s Settings, and switch on Include experimental audits under Scan settings. The setting is per-site, and applies to every scheduled and manual scan of that site from the moment you save it.

How the audit works

The audit reads every element with the tab or tabpanel role, including hidden ones, since the hidden panel of an inactive tab is the correct pattern. A tab and a tab panel are associated when the tab’s aria-controls names the panel, or the panel’s aria-labelledby names the tab.

These are reported as violations:

• Tab used as a link: the tab is, or sits inside, a link to another page.
• Tab without a panel: the page has no tab panels, or every tab panel is already associated with another tab.
• Tab panel without a tab: the page has no tabs, or every tab is already associated with another panel.

The audit never guesses which panel belongs to which tab. A violation only means there is no panel (or tab) left over for it.

Reading the results

Violations are tabs and tab panels that provably have no counterpart. Incomplete results need human review. They are tabs and panels with no declared association where one might still exist, such as when some tab panels are not connected to anything, or a tab whose aria-controls points at an element without the tab panel role.

To fix a violation, connect each tab to the panel it shows with aria-controls. If the “tabs” are really links to other pages, remove role="tab" and role="tablist", mark the links up as a list inside a nav element, and use aria-current="page" on the current link.

You can ignore individual elements you have reviewed and accepted using the same ignore feature you use for other issues.

Limitations

The audit checks that an association exists, not that it is the right one, and it does not test keyboard behavior, aria-selected, or whether activating a tab shows its panel. Tabs inside shadow roots, and custom elements that get their role without a role attribute, are not checked.

Tab widgets that a script wires up only after a tab is first activated, or that render their panels later, are reported as incomplete until the association exists.