WCAG 1.4.13 Content on Hover or Focus: How to Handle Tooltips and Popups

What WCAG 1.4.13 covers

WCAG 1.4.13, introduced in WCAG 2.2 at Level AA, targets content that appears when a control receives hover or keyboard focus. This includes tooltips, flyouts, popovers, dropdowns and similar transient UI. The goal is simple: users who rely on keyboard or assistive technology must be able to reveal, read and dismiss that content reliably.

Why this matters for tooltips and popups

Many tooltips are written for mouse users only. That makes the same information invisible to keyboard users and screen reader users. Poorly implemented popups can trap focus, disappear while someone tries to move the pointer, or be impossible to close without a mouse. Meeting 1.4.13 prevents those failures.

Practical requirements (how to think about the rule)

• Make content revealable using keyboard focus as well as pointer hover.
• Allow the pointer to move into the revealed content without it disappearing.
• Provide a simple, obvious way to dismiss the content from keyboard and pointer, such as the Escape key and a visible close control.
• Do not rely solely on the browser title attribute for important information.

When to use tooltip, popover or dialog

Choose the widget that matches the content and its needs.

• Tooltip: Short, non-interactive text that supplements an element. Use only for brief clarification.
• Popover (disclosure): Small panel that can contain links or controls. Use when the user needs to interact with the content.
• Dialog: Use when the content is modal and the user must complete an action before continuing.

Recommended ARIA and HTML patterns

Match the markup to the widget role.

• Non-interactive tooltip: use aria-describedby on the trigger pointing to the tooltip element. The tooltip element may use role=“tooltip”.
• Interactive popover: use aria-haspopup on the trigger (value dialog or menu as appropriate) and manage focus so keyboard users can enter and exit the popover.
• Modal dialog: use role=“dialog” with accessible name, trap focus while open, and restore focus to the trigger when closed.

Keyboard behaviour — concrete rules

• Ensure the trigger can be focused by keyboard (use native controls or tabindex=“0”).
• Make the same user action that reveals the content via pointer also work with keyboard focus. For example a trigger that shows content on hover should also reveal on focus.
• If the revealed content is interactive, allow tabbing into it and tab back out in a logical order. If it is modal, trap focus inside until dismissed.
• Support Escape to dismiss the content and return focus to a sensible element, usually the trigger.

Pointer behaviour — avoid flicker and accidental close

• When hover reveals content, allow a small pointer gap or use a short delay so moving the pointer into the panel does not hide it immediately.
• Do not hide the panel when the pointer moves from the trigger into the revealed content.
• Provide a visible close control inside the panel for pointer users.

Mobile and touch specifics

Touch devices do not have hover. Always provide a tap mechanism to reveal content. For short text, consider inline expansion in the page flow. For interactive content, provide a clear close control and ensure the popover size and touch targets meet minimum sizes.

Testing checklist

Run these checks for each tooltip, popover or flyout.

1. Keyboard only: Tab to the trigger, verify it opens on focus, tab into content if interactive, press Escape to close.
2. Pointer: Hover the trigger, move pointer into panel, verify it stays visible and close control works.
3. Screen reader: Use NVDA or VoiceOver. Confirm the content is announced or reachable via aria-describedby and interactive controls are reachable.
4. Touch: Tap to open, tap the close control or outside to close. Ensure no hover-only content exists.
5. Automated checks: run Axe or WAVE to catch missing roles, focus traps and contrast issues. Use manual testing for behaviour that tools cannot detect.

Common implementation mistakes

• Relying only on the title attribute for essential information. Many screen readers ignore it.
• Showing content only on hover and not on focus.
• Removing content as soon as pointer leaves the trigger, preventing entry to the panel.
• Failing to provide a keyboard method to dismiss the panel.
• Using wrong ARIA roles and not moving focus for interactive popovers.

Decision flow: quick rules to apply

• If the text is short and non-interactive, implement a tooltip with aria-describedby and ensure it appears on focus.
• If content contains links or form fields, use a popover with keyboard focus support.
• If the content requires the user to complete or cancel a task, use a modal dialog with proper focus trapping and an accessible name.

Summary checklist to hit WCAG 1.4.13

• Content appears on both hover and focus.
• Pointer can move into revealed content without it hiding.
• There is a keyboard method to dismiss, including Escape.
• Interactive panels accept and return focus correctly.
• Do not rely on title for required information.
• Test with keyboard, screen readers and touch devices.

Meeting WCAG 1.4.13 often requires small code and interaction changes. Start by identifying hover-only elements, then add focus handlers, a clear close action and proper ARIA markup. That delivers content that is usable by everyone.