WCAG 1.4.13 governs the extra content that appears when a user hovers a pointer over an element or moves keyboard focus to it — custom tooltips, flyout submenus, and non-modal popups. To pass at Level AA, that content must be dismissible, hoverable, and persistent so people can actually read it and close it without losing their place.

What 1.4.13 actually requires

The official wording from the W3C Understanding document is that where “receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden,” three conditions must all be true:

  • Dismissible — A mechanism lets the user dismiss the content without moving pointer hover or keyboard focus. Pressing the Escape key is the standard method. (Exception: content that reports an input error, or that doesn’t obscure or replace other content, is exempt from this part.)
  • Hoverable — If hover triggers the content, the pointer can be moved onto the new content without it disappearing. A tooltip you can’t reach with the mouse fails.
  • Persistent — The content stays visible until the user removes the trigger, dismisses it, or the information is no longer valid. It must not auto-vanish on a timer.

One carve-out: content whose visual presentation is controlled by the browser and not modified by the author is exempt. Native HTML title tooltips don’t count — 1.4.13 is about the custom hover and focus UI you build yourself. Modal dialogs are also out of scope.

Who this affects

This criterion protects several groups the W3C calls out specifically:

  • People using screen magnification. At 200–400% zoom, a popup 100px from the trigger may sit entirely outside the magnified viewport. The user must pan the pointer toward it — and if the content vanishes the instant the pointer leaves the trigger, they can never read it.
  • People with large mouse cursors set through the OS or assistive tech, whose pointer covers the very content they’re trying to inspect.
  • People with low pointer accuracy — tremor, limited dexterity, or a head-pointer — who can’t hold the cursor still on a tiny trigger.
  • People with cognitive disabilities who need adequate time to perceive content before it disappears.
  • Keyboard-only users, who depend on focus (not hover) to surface the same content. A tooltip that only shows on :hover gives them nothing.

Concrete failures (and the fixes)

Failure 1: the tooltip you can’t reach

This is the canonical failure, documented by W3C as F95: content shown on hover is not hoverable. The popup is bound to the trigger only, so the moment the pointer moves off the trigger toward the popup, it closes. A magnification user can never get the content into view.

A common broken pattern keeps the popup open only while the trigger is hovered:

/* FAILS 1.4.13: popup closes as soon as you leave .trigger */
.trigger:hover + .tooltip { display: block; }

The fix is to keep the content visible while the pointer is over either the trigger or the popup — and let focus do the same thing. Wrap both in a shared container with no gap, so the pointer can travel onto the content:

/* PASSES: a single hover/focus zone covers trigger AND tooltip */
.tip-wrap:hover .tooltip,
.tip-wrap:focus-within .tooltip { display: block; }

If there’s a visual gap between trigger and popup, bridge it with an invisible padding area or position the popup flush, so the pointer never crosses “dead” space that closes it.

Failure 2: no way to dismiss without moving the mouse

A popup that covers the field below it, with no Escape handling, traps a magnification user: the only way to clear it is to move the pointer, which may land on another trigger. The W3C technique SCR39 covers making content hoverable, dismissible, and persistent with scripting. Add an Escape handler:

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

Failure 3: hover-only content with no focus path

A ”?” help icon that only reveals its tip on mouse hover gives keyboard and screen-reader users nothing. Make focus mirror hover, expose the content with aria-describedby, and give the popup role="tooltip" so assistive tech announces it:

<button aria-describedby="pwd-tip">Password rules</button>
<div id="pwd-tip" role="tooltip">8+ characters, one number.</div>

Failure 4: the disappearing flyout menu

A navigation submenu that snaps shut the instant the pointer dips below the parent link — before reaching the submenu — fails both hoverable and persistent. Keep the parent and submenu in one hover region and add a short close delay so an imprecise pointer doesn’t dismiss it.

How to test for 1.4.13

You can verify this by hand in a few minutes — automated scanners rarely catch it because passing requires behavioral checks no static rule can judge:

  1. Hover, then travel. Hover each tooltip, submenu, or popup, then move the pointer slowly onto the new content. It must stay open the whole way. If it closes, that’s F95.
  2. Press Escape. With the popup open, hit Escape without moving the mouse. The content should dismiss. If it can’t, it fails dismissible (unless it’s an error message or doesn’t obscure anything).
  3. Wait. Leave the trigger active and count to ten. The content must not auto-hide on a timer; it should persist until you move away or dismiss it.
  4. Tab to it. Unplug the mouse. Tab to the trigger — the same content must appear on focus, not just on hover.
  5. Zoom to 400%. Turn on browser zoom or OS magnification and repeat. This is where real-world failures surface, because the popup may render off-screen.

Why this matters legally

WCAG 2.1 AA is the practical benchmark courts and the DOJ apply to an accessible website under ADA Title III, and 1.4.13 is part of that AA baseline. What makes this criterion distinctly litigable is that the harm is recordable on video. Most low-vision plaintiffs in digital-access suits are screen-magnification users — the exact group W3C names as the primary beneficiary, noting that 1.4.13 lets “users with low vision who view content under magnification” read hover content “without reducing their desired magnification” (W3C Understanding 1.4.13).

That is precisely the evidence a tester captures. At 300% zoom the magnified viewport shows only a fraction of the page, so a popup that closes the instant the pointer leaves the trigger — the F95 failure — is impossible to reach, and a tester can film the tooltip flickering shut as the cursor pans toward it. There is no ambiguity to argue: the content the magnification user is entitled to read literally cannot be brought into the viewport. A price tooltip, a coupon-code popover, or a checkout help bubble that vanishes under zoom is a clean, demonstrable barrier — far harder to dispute than a contrast value someone debates in pixels. UsableNet’s 2024 year-end report counted over 4,000 ADA digital lawsuits, with more than 1,000 businesses sued despite having an accessibility widget installed — because a widget cannot change how your popup behaves when the pointer travels onto it.

This is general information, not legal advice. For your specific situation, consult a qualified attorney.

Why an overlay can’t fix this one

Of all the AA criteria, 1.4.13 is among the worst fits for an accessibility overlay — because passing it means changing the behavior of a popup your code already built, not adjusting a property after the fact. Each of the three conditions defeats the overlay model directly:

  • Hoverable requires merging the trigger and the popup into one continuous hover region (the :focus-within shared-zone pattern above). An overlay script doesn’t know which floating <div> belongs to which trigger, where the dead space between them is, or which CSS rule closes the popup. It can’t re-architect your hover geometry from the outside.
  • Dismissible requires an Escape handler wired to your show/hide logic. The overlay can listen for the Escape key, but it has no reference to your component’s open/close state, so it can’t actually hide the tip without breaking it.
  • Persistent requires removing whatever timer or mouseleave rule auto-dismisses the content. That logic lives inside your component; an injected script can’t safely rewrite it.

There’s also role="tooltip" and aria-describedby, which must sit on the correct element to announce correctly — a binding only someone reading your markup can get right. This is why the Overlay Fact Sheet, signed by hundreds of accessibility practitioners, warns that overlay “remediation” is typically applied only to the injected script and not the underlying code — so the instant a user blocks or disables the widget, the inaccessible popup is fully exposed again. The American Foundation for the Blind makes the same point for this exact audience: magnification users already run their own magnifier and won’t adopt an overlay’s parallel tooling.

Curbcut is deliberately anti-overlay. Our [EXPERT_NAME] team rebuilds hover and focus content by hand so tooltips and menus are genuinely dismissible, hoverable, and persistent — then verifies it against the rules they touch, like keyboard navigation and a visible focus indicator. Because focus has to reveal what hover does, the same ARIA roles and labels carry the content to screen readers.

Not sure which popups on your site fail? An accessibility audit finds them all, or start with a free scan and we’ll show you where your hover content breaks — then remediate it in your code so the default experience passes.