Labeling
Tooltip content should supplement a control, not replace its label. The trigger should already be understandable before the tooltip opens.
Keyboard Behavior
AnnouncementFocus the demo and press a key from the table.
| Key | Action |
|---|---|
| TabShift + Tab | Moving the focus to the trigger from the keyboard shows the tooltip after delayOpen, or at once right after another tooltip closed; moving it away hides the tooltip. |
| Escape | Hides the open tooltip. The focus stays on the trigger. |
A tap never shows the tooltip, so touch users do not see it; keep anything they need visible elsewhere.
Focus Behavior
- Opening a tooltip should not destabilize focus.
- Tooltips inside overlays should still be tested in the real stack.
Screen Reader Semantics
- The trigger should already be meaningful.
- While the tooltip is open, the trigger points to its
role="tooltip"content througharia-describedby. - Tooltip content should remain supplemental.
Form Semantics
- Tooltips are useful for optional field help, not for required validation instructions.
- If the surrounding form depends on the content, it should be visible outside the tooltip.
Accessibility Risks
- Making the tooltip the only accessible name of a control.
- Placing required instructions only inside the tooltip.
- Putting interactive flows into tooltip content.