Skip to content
A11ySignal
seriousWCAG 4.1.2 · A

ARIA tooltip nodes must have an accessible name

aria-tooltip-name

Ensure every ARIA tooltip node has an accessible name

The criterion behind it

4.1.2 Name, Role, Value

Every control must expose what it is, what it is called, and what state it is in.

Level A · EN 301 549 § 9.4.1.2

Why this check exists

This is the criterion custom components break. A `div` styled as a checkbox tells assistive tech nothing about being checked.

What usually triggers it

  • failsA `<div>` toggle with no `role="switch"` and no `aria-checked`.
  • failsAn icon button with no accessible name.
  • failsAn accordion whose header never updates `aria-expanded`.
  • failsA custom `<select>` with no `role="combobox"` and no `aria-activedescendant`.

How to fix it

  • doUse the native element wherever one exists. `<button>`, `<input type="checkbox">` and `<select>` get all of this for free.
  • doFor a genuinely custom widget, follow the ARIA Authoring Practices pattern for it, including keyboard behaviour.
  • doKeep state attributes in sync with what is on screen.

How it is reported

A11ySignal reports this at serious impact. Every failing element comes with its CSS selector and the markup that failed, so you can go straight to the line rather than hunting for it. Deque publishes the engine-level detail:

https://dequeuniversity.com/rules/axe/4.13/aria-tooltip-name

Check implemented by axe-core 4.13.0, © Deque Systems, MPL-2.0.

Other checks for 4.1.2