In one paragraph
ARIA tab nodes must have an accessible name means a tested tab does not identify which panel it selects. Use meaningful visible wording or an appropriate icon-tab name, and preserve it across responsive states. A name alone does not implement tab selection, panel relationships, focus movement, or keyboard behaviour. Test the complete tabs pattern as well as the relevant naming findings.
Why it matters
Users choose among panels based on their labels. Tab 2 may satisfy a non-empty string test but fails to explain whether it contains pricing, settings, or notifications. Names should remain useful without requiring people to open every panel first.
Responsive designs often hide visible text and leave only artwork. If the same text is also removed from accessibility exposure and no other name exists, an otherwise working desktop implementation can become unnamed on mobile.
Tabs are not merely several buttons with special styling. Their tablist, tab and tabpanel relationships, selected states, focus strategy, and activation behaviour form one coordinated pattern. Adding role=tab does not install arrow-key navigation or panel switching.
How WebAuditOS evaluates this finding
The supplied aria-tab-name rule checks applicable visible explicit tab roles through text, supported ARIA naming, or title fallback. It describes native button and anchor exclusions that route naming responsibility to neighbouring rules; verify those selectors against the deployed axe version.
Serious impact maps to high severity. Hidden or later-created tabs can escape the snapshot, and a pass does not validate label usefulness, panel correspondence, or interaction. Review other naming findings when the expected tab-specific one is absent.
How to fix it
- Identify the panel choices and give each a concise truthful label. Keep label text tied to the actual panel content and localise it with the rest of the interface.
- Prefer visible text where practical. A structural single-pair illustration is:
<button type="button" role="tab" id="overview-tab" aria-selected="true" aria-controls="overview-panel">Overview</button>
<section role="tabpanel" id="overview-panel" aria-labelledby="overview-tab">Overview content</section>This is not a complete tabs implementation. The containing tablist, additional choices, activation, and keyboard logic must be designed and tested together.
- For icon-only tabs, provide a correct accessible name and hide decorative artwork only when the name remains available. Do not leave the control with an unexplained glyph or label every icon Tab.
- Preserve naming at narrow widths. A visually hidden text technique can retain a name, while display:none or inappropriate aria-hidden can remove ordinary naming content. Inspect the computed result rather than the CSS class name.
- Keep IDs unique and relationships correct for repeated tab groups. Do not point every tab to one stale panel identifier copied from a component example.
- Follow the appropriate tabs keyboard and activation design. Selection and focus are related but not always identical; choose manual or automatic activation according to the content and expected latency.
- Test arrow navigation, entering and leaving the tab group, selected state, hidden panels, and focus visibility. Review asynchronous panel loading and route updates so names and content do not drift apart.
- Rescan mobile and desktop states and inspect native button or link name findings too. An element excluded from this rule still needs the applicable name and full interaction.
What the fix can break
An aria-label can override useful visible text. Keep the name consistent with what users see and say for voice interaction.
Switching selection on every focus event can be frustrating when panels load slowly. A structural naming repair should not silently change the activation model.
Do not hide tab labels from everyone to create a cleaner layout without an equivalent. Responsive styling should preserve the same understandable choices.
Questions
Why is an icon tab unnamed only on mobile?
Its text may be removed at that breakpoint. Inspect the active DOM and computed name at both widths.
Does role=tab add arrow-key handling?
No. Implement and test the complete pattern, including focus and selection.
Why can the issue appear under button naming instead?
The supplied rules have element-specific applicability. A different finding label can represent the same user need.
Which related checks help?
Review required children, button names, and the automation limits guide.
What severity does this get in the report?
High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. axe declares this rule serious, so a failure arrives as high. The panel above shows a conformance level because for axe rules severity comes from the scan.