Content on hover or focus cannot be dismissed

What is this issue?

Content that appears only when a user hovers a pointer over, or moves keyboard focus to, a trigger element (a tooltip, an info popup, a preview card) fails to meet one or more of three specific requirements WCAG 1.4.13 sets for that pattern: the content must be dismissible (closeable without moving the pointer or focus, typically with Escape), hoverable (a user can move their pointer onto the revealed content itself without it disappearing), and persistent (it remains visible until the trigger is deactivated, the user dismisses it, or its information is no longer valid, not on a fixed timeout).

The most common real-world violation is the native title attribute, which fails all three at once: it disappears the instant the pointer moves toward it, offers no dismiss mechanism, and vanishes after a browser-controlled delay regardless of whether the user finished reading it.

Why does this matter?

Someone using screen magnification typically sees only a small portion of the screen at full zoom, and the area where a tooltip appears is often outside their currently visible region. Reading it requires physically moving their view, panning the magnifier or moving the pointer toward the tooltip, and if that same movement causes the tooltip to disappear, the content becomes permanently unreachable no matter how many times they try.

The same failure mode affects anyone who needs more time to read text than the trigger’s hover state naturally lasts, or anyone whose pointer control makes precisely holding a hover position difficult. A tooltip that vanishes the moment the mouse so much as twitches off the trigger element punishes exactly the kind of imprecise, exploratory pointer movement that makes hover interactions hard for many users to begin with.

Who is affected?

• Low vision users, using screen magnification, see only part of the screen at once, and moving toward a tooltip to read it at higher zoom is exactly the movement that dismisses a non-hoverable tooltip before it can be read.
• Motor impairments: someone with limited fine motor control who has difficulty holding a precise pointer position, or who uses a device that doesn’t support a stable “hover” state at all, needs a way to keep content open without maintaining continuous, exact positioning.
• Keyboard users: focus-triggered content that disappears the instant focus moves to the next element, with no way to review it again, gives keyboard users no opportunity to interact with anything the tooltip itself contains.

What users experience

Elena has low vision and uses 300% screen magnification in her browser. She’s filling out a form with a small “?” icon next to the “Routing number” field, which shows a tooltip explaining the format on hover. At her zoom level, the tooltip appears mostly outside her currently visible viewport, so she moves her mouse toward it to read the rest. Because it’s implemented with the title attribute, moving the pointer toward the tooltip dismisses it instantly. She tries four more times, moving progressively more carefully, before giving up and guessing at the field’s expected format.

How do I fix it?

Build hover and focus content as a custom tooltip pattern instead of relying on the title attribute, and give it Escape-key dismissal, hover-through behavior, and persistence until the user moves away or closes it. This works because a custom implementation gives you control over all three of 1.4.13’s requirements at once, whereas title is entirely browser-controlled and can’t be made to satisfy any of them.

Wire an Escape keydown listener to close the tooltip, and add a mouseenter listener on the tooltip content itself (not just the trigger) that keeps it open; this is what makes the tooltip hoverable, since without it, moving the pointer off the trigger and onto the tooltip’s own bounding box still counts as leaving and closes it. Keep the tooltip open until one of those explicit close conditions fires, rather than closing it on a fixed timer.

Code Examples

<!-- title tooltip: not dismissible, not hoverable, disappears fast -->
<button title="Your routing number is the 9-digit number on your check.">
  Routing number ⓘ
</button>

<div class="tooltip-wrapper">
  <button aria-describedby="routing-tooltip">
    Routing number ⓘ
  </button>
  <div id="routing-tooltip" role="tooltip" class="tooltip">
    Your routing number is the 9-digit number on your check.
  </div>
</div>

const wrapper = document.querySelector('.tooltip-wrapper');
const tooltip = document.getElementById('routing-tooltip');
const trigger = wrapper.querySelector('button');

function showTooltip() { tooltip.classList.add('visible'); }
function hideTooltip() { tooltip.classList.remove('visible'); }

// Dismissible: Escape closes it regardless of pointer/focus position
document.addEventListener('keydown', (event) => {
  if (event.key === 'Escape') hideTooltip();
});

// Hoverable: moving onto the tooltip itself keeps it open
trigger.addEventListener('mouseenter', showTooltip);
tooltip.addEventListener('mouseenter', showTooltip);
wrapper.addEventListener('mouseleave', hideTooltip);

// Persistent: also shows and stays open on keyboard focus
trigger.addEventListener('focus', showTooltip);
trigger.addEventListener('blur', hideTooltip);

The Escape listener satisfies dismissible: the user can always close the tooltip without needing to move their pointer anywhere specific. Attaching mouseenter to the tooltip itself, not just the trigger, satisfies hoverable, since the pointer moving from the trigger onto the tooltip’s own area no longer counts as “leaving.” Removing any fixed-duration timeout and closing only on Escape, blur, or genuinely moving away satisfies persistent.

Common Mistakes

Mistake: “The title attribute is built into HTML, so it must be accessible by default.” title fails all three of 1.4.13’s requirements at once: it isn’t dismissible, isn’t hoverable (moving toward it dismisses it), and isn’t persistent (it disappears after a short, browser-controlled delay). Native does not mean accessible here; title was never designed to meet this criterion.

Mistake: “Adding a longer timeout, like 10 seconds instead of 3, satisfies the persistent requirement.” Persistent doesn’t mean “long enough for most people”; it means the content stays visible until the user actively dismisses it or moves away, with no timer at all. Any fixed timeout, however generous, still fails for a user who happens to need more time than that specific number.

Mistake: “Making the tooltip dismissible with a close button is enough, even if hovering onto it still closes it.” All three requirements are independent and all three must be met: a tooltip with a working close button but no hover-through behavior still fails as soon as a user’s pointer moves toward the content to read it, well before they reach any close button.

Mistake: “This rule only applies to text tooltips.” It applies to any content that only appears through hovering or focusing a trigger: image previews, rich popups with links and buttons inside them, expanded card previews. Any hover/focus-revealed content needs the same three properties regardless of what it contains.

How RedFlag Detects This

Guidance only: RedFlag documents this issue but does not currently flag it; verify manually. RedFlag’s coverage matrix records criterion 1.4.13 Content on Hover or Focus under docs_only evidence. Verifying whether hover/focus content is dismissible, hoverable, and persistent requires simulating real pointer movement over time and observing the resulting behavior, which RedFlag’s static DOM scan does not perform.

False negative: every occurrence is a false negative in the sense that nothing is ever automatically flagged: a page using title attributes or a custom tooltip that fails all three requirements passes every RedFlag scan silently. False positive: not applicable, since this check never raises an automated violation to begin with. Manual step: trigger every hover/focus tooltip on the page, try pressing Escape, try moving the pointer onto the tooltip content itself, and time how long it stays open without any interaction, confirming all three requirements hold.

Manual Testing

1. Open the page in Chrome or Firefox and identify every element that reveals content on hover or keyboard focus.
2. Trigger the content and press Escape; it should close without requiring you to move the pointer anywhere specific.
3. Trigger the content again and move your pointer directly onto the revealed content itself; it should stay open, not disappear.
4. Trigger the content a third time and simply wait without moving anything; it should remain visible indefinitely, not vanish after a fixed delay.
5. Repeat with keyboard-only focus (Tab to the trigger, no mouse) to confirm the same three behaviors hold for focus-triggered content, not just hover-triggered content.
6. If any of the three checks fails, the rule fails.

Related WCAG Success Criteria

1.4.13 Content on Hover or Focus: Additional content that appears on hover or focus must be dismissible, hoverable, and persistent, unless the content is a native browser feature the page’s author doesn’t control. This rule is a direct check of all three requirements together.

Related Issues

Tooltip element is missing an accessible name covers a related but distinct requirement for the same component type: whether a role="tooltip" element has a name assistive technology can announce, separate from whether the tooltip’s interaction behavior meets 1.4.13.

Text contrast fails after a hover, focus, or state change shares this rule’s hover/focus trigger mechanism, applied to a color-contrast failure instead of a dismissal/persistence failure.

Focused element is hidden behind a sticky header or footer shares the broader theme of content becoming unreachable due to how it’s positioned relative to where the user’s attention already is.

Status messages are not announced to assistive tech and this rule both concern dynamically appearing content that needs to reliably reach the user: one through screen reader announcement, this one through sustained visual and pointer access.

Hidden component exposed to screen readers is the inverse failure in the same dynamic-visibility family: content that’s exposed when it shouldn’t be, rather than content that disappears before it should.

References

• W3C Understanding 1.4.13: Content on Hover or Focus
• ARIA Authoring Practices: Tooltip Pattern
• MDN: title attribute