In one paragraph
ARIA tooltip nodes must have an accessible name means a tested exposed tooltip lacks the content or name accepted by this rule. Supply useful text and connect it to the triggering element appropriately. The trigger still needs its own name, and tooltip behaviour requires separate testing. An empty transparent container is not necessarily hidden from accessibility APIs, while a closed dynamic tooltip may be outside the scan.
Why it matters
A tooltip supplements another element with a short description. It should not be the sole unreliable place where an essential action or field question is communicated. The owning control needs a clear identity even before supplementary help is read.
The usual ARIA relationship is aria-describedby from the trigger to the tooltip. Naming the tooltip itself is not the same as ensuring the trigger receives that description. An aria-label that overrides the tooltip's actual content can make the intended explanation less useful.
Hover content also has interaction requirements. Keyboard users need appropriate access and dismissal, and the content should remain available under the applicable hover/focus conditions. If the popup contains focusable links or actions, a tooltip may be the wrong pattern.
How WebAuditOS evaluates this finding
The supplied aria-tooltip-name rule checks exposed explicit tooltip roles and recognises text or supported author naming paths. It can inspect a transparent or off-screen container that remains in the accessibility tree.
Serious impact maps to high severity. The scan described in the source does not hover or focus every trigger, so tooltips created only during interaction can go untested. The naming rule does not establish a correct trigger relationship, useful content, Escape handling, or complete hover/focus conformance.
How to fix it
- Inspect the actual tooltip container, its content, and the trigger. Determine whether it is an empty abandoned shell, a truly closed widget, or an active description with broken output.
- Provide meaningful text rather than a generic non-empty label. A structural illustration is:
<button type="button" aria-describedby="copy-help">Copy link</button>
<div role="tooltip" id="copy-help">Copies this page address to the clipboard.</div>This does not implement show/hide timing or copying. A production tooltip needs the correct dynamic behaviour and an actual control action.
- Keep the trigger's accessible name distinct from supplementary description. Do not expect an unexplained icon to become a clearly named button just because a tooltip exists elsewhere.
- Manage closed containers deliberately. Removing or appropriately hiding unused tooltip content can avoid exposing an empty role, but explicit references to hidden descriptions follow their own naming rules. Inspect the computed description instead of assuming every hidden node is unreadable.
- Test focus and hover entry, pointer movement over the tooltip, persistence while needed, and Escape dismissal. The APG tooltip guidance is work in progress; use relevant WCAG requirements and real interoperability testing rather than treating a draft pattern as a conformance certificate.
- Keep keyboard focus on the appropriate trigger for a noninteractive tooltip. If users must operate controls inside the popup, select and implement a suitable dialog or popover interaction instead.
- Review touch and magnification behaviour so help is not exclusively mouse-hover content. Keep essential instructions persistently available where the task requires them.
- Rescan initial exposed content and manually test dynamic states. A quiet load-time result cannot validate the tooltips that appear only after user input.
What the fix can break
Removing an empty shared container can break a tooltip library if it expects to reuse it. Repair its lifecycle rather than deleting arbitrary nodes after every render.
Adding a separate name can override meaningful tooltip text in some accessibility computations. Check the trigger's actual description and avoid redundant or misleading announcements.
Do not put interactive help into role=tooltip and then force focus into it. That contradicts the simple descriptive pattern and needs a different complete design.
Questions
Does a named tooltip automatically name its trigger?
No. The control's name and its supplementary description are separate relationships.
Why was an invisible container tested?
Opacity or positioning alone may leave it exposed to accessibility APIs. Inspect the actual hidden state.
Can the tooltip contain buttons?
A focusable interactive popup needs an appropriate different pattern rather than assuming simple tooltip semantics cover it.
Which related checks help?
Review hidden focus, 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.