Accessible Tooltip and Popover Design: Hover, Focus, and Persistence

Tooltips and popovers deliver supplementary information on demand — definitions, descriptions, formatting hints, and contextual help. When they appear only on mouse hover, keyboard and screen reader users miss the information entirely. When they disappear too quickly, users with motor impairments or low vision cannot read them. WCAG 2.2 Success Criterion 1.4.13 (Content on Hover or Focus) codifies the requirements for making this pattern inclusive.

Tooltips vs. Popovers vs. Toggletips

These terms are often used interchangeably, but they describe different patterns:

Tooltip: A small text label that appears on hover/focus to describe or name a control. Tooltips provide the accessible name or description — they do not contain interactive content. The W3C ARIA role="tooltip" is used for this pattern.

Popover: A richer content container that may include formatted text, links, images, or actions. Popovers are essentially non-modal dialogs and should follow the dialog pattern when they contain interactive content.

Toggletip: A tooltip-like element triggered by a button click rather than hover. Toggletips are more accessible by nature because they use an explicit activation mechanism rather than hover.

The ARIA Tooltip Pattern

<button aria-describedby="save-tip">
  <svg aria-hidden="true"><!-- save icon --></svg>
  <span class="visually-hidden">Save</span>
</button>
<div role="tooltip" id="save-tip">Save your current progress (Ctrl+S)</div>

Requirements

• role="tooltip" on the tooltip container
• aria-describedby on the trigger element pointing to the tooltip’s id
• Tooltip appears on both hover and focus of the trigger element
• Tooltip text is plain text — no interactive elements inside a tooltip

When the trigger receives focus, the screen reader announces both the button’s accessible name (“Save”) and its description (“Save your current progress, Ctrl+S”) because of the aria-describedby relationship.

WCAG 1.4.13 Requirements

Content that appears on hover or focus must meet three conditions:

1. Dismissible

Users must be able to dismiss the tooltip without moving hover or focus. The standard mechanism is the Escape key. This allows users to dismiss tooltips that obscure other content they are trying to read.

document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') {
    hideAllTooltips();
  }
});

2. Hoverable

Users must be able to move their pointer over the tooltip content without it disappearing. This is critical for users with low vision who use screen magnification — they need to hover over the tooltip to read it within their magnification window.

.tooltip-trigger:hover + .tooltip,
.tooltip:hover {
  display: block;
}

The tooltip must remain visible when the pointer moves from the trigger to the tooltip itself. A common failure is dismissing the tooltip when the pointer leaves the trigger, even if it enters the tooltip area.

3. Persistent

The tooltip must remain visible until the user dismisses it (Escape), moves hover away from both trigger and tooltip, or removes focus from the trigger. Tooltips must not disappear on a timer.

Toggletip Pattern

Toggletips provide a more robust alternative to hover-triggered tooltips:

<button aria-expanded="false" aria-controls="info-tip">
  <svg aria-hidden="true"><!-- info icon --></svg>
  <span class="visually-hidden">More information</span>
</button>
<div id="info-tip" role="status" hidden>
  This field accepts international phone numbers including country code.
</div>

Advantages over hover tooltips:

• Work on touch devices (no hover state)
• Use familiar button interaction (click/Enter/Space)
• aria-expanded communicates state clearly
• Can contain richer content including links
• role="status" announces content to screen readers when revealed

When to use toggletips:

• Touch-primary interfaces
• When tooltip content is essential rather than supplementary
• When tooltip content includes links or interactive elements
• When the information would benefit from persistence (user clicks to open, clicks again to close)

Design Guidelines

Positioning

• Place tooltips near their trigger element, typically above or below
• Ensure tooltips do not overflow the viewport — implement collision detection to flip position when near edges
• Maintain adequate spacing between the tooltip and trigger to support the hoverable requirement

Content

• Keep tooltip text concise — one to two sentences maximum
• If more content is needed, use a toggletip or popover instead
• Never put essential information only in a tooltip. If the information is required to complete a task, make it visible by default or use a persistent help text pattern
• Write in plain language, avoiding jargon that adds cognitive load

Visual Design

• Use sufficient contrast between tooltip text and background (minimum 4.5:1 for normal text per WCAG 1.4.3)
• Provide a visible border or shadow to distinguish the tooltip from underlying content
• Include a visual arrow or caret pointing to the trigger element for spatial association
• Respect reduced motion preferences if the tooltip uses entry animations

Touch Devices

Tooltips triggered by hover are inaccessible on touch devices by default. Options:

1. Toggletip pattern: Convert hover tooltips to click-triggered toggletips on touch devices
2. Long-press: Show tooltip on long-press, though this is a non-standard pattern with discoverability issues
3. Always visible: For critical information, show the text inline rather than hiding it behind a tooltip

Interactive Popovers

When your “tooltip” contains links, buttons, or other interactive elements, it is not a tooltip — it is a popover. Use the dialog pattern:

<button aria-expanded="false" aria-controls="user-popover">
  Account Settings
</button>
<div id="user-popover" role="dialog" aria-label="Account options" hidden>
  <a href="/profile">Edit Profile</a>
  <a href="/settings">Preferences</a>
  <button>Sign Out</button>
</div>

Popovers with interactive content should trap focus and close on Escape, following the same rules as modal dialogs but without the background overlay.

Common Mistakes

1. Using title attribute as a tooltip: The title attribute has inconsistent screen reader support, does not appear on focus, cannot be styled, and disappears on a timer. Avoid it for tooltips.
2. Hover-only triggers: If it appears on hover, it must also appear on keyboard focus. No exceptions.
3. Tooltips that disappear when moving to hover over them: Violates WCAG 1.4.13’s hoverable requirement.
4. Interactive content inside role="tooltip": Tooltips should contain only text. Use dialog/popover for interactive content.
5. Tooltip as the only accessible name: If a button has no visible text and its only accessible name comes from a tooltip, the tooltip content should be the button’s aria-label, not just aria-describedby.

Testing

• Hover: Point to the trigger. Tooltip appears. Move pointer to the tooltip. It persists. Move pointer away. It dismisses.
• Focus: Tab to the trigger. Tooltip appears. Press Escape. Tooltip dismisses. Tab away. Tooltip dismisses.
• Screen reader: Focus the trigger. Verify the tooltip content is announced as part of the element’s description.
• Touch device: Verify the tooltip information is accessible through tap, toggletip, or inline display.
• Magnification: At 200% zoom, verify the tooltip is readable and hoverable within a magnified viewport.

Key Takeaways

Accessible tooltips require hover plus focus activation, Escape dismissal, and pointer hoverability. For richer content or touch-first interfaces, toggletips and popovers provide better accessibility out of the box. Reserve role="tooltip" for plain text descriptions and use dialog patterns for interactive content. Never hide essential information behind a tooltip — if users need it to complete a task, make it visible by default.

Sources

• WCAG 2.2 SC 1.4.13 Content on Hover or Focus — The requirements for tooltip persistence and dismissibility.
• W3C WAI-ARIA APG: Tooltip Pattern — The ARIA tooltip widget pattern.
• Deque University: Tooltip Accessibility — Accessible tooltip implementation examples.
• WebAIM: ARIA and Accessibility — Practical ARIA guidance including tooltip patterns.