WCAG 1.4.13 — Content on Hover or Focus

What this requires

When additional content appears on hover or focus and disappears again, it must satisfy three conditions:

Dismissible — the user can dismiss the content without moving pointer or focus (Escape closes the tooltip while the trigger keeps focus).
Hoverable — the user can move the pointer over the appearing content without it disappearing. Magnifier users in particular need this.
Persistent — the content stays visible until the hover, focus, or dismissal is removed, or the content is no longer valid.

The criterion targets tooltips, hover menus, focus-revealed help panels, and similar UI.

How AI coding tools fail this

When asked for "a tooltip on this icon", AI tools often reach for title="..." (which is non-interactive and inaccessible) or build a pure-CSS :hover reveal with no JavaScript to handle Escape, focus, or pointer-on-tooltip behaviour.

The second pattern: tooltips wired to onMouseEnter/onMouseLeave on the trigger only. The user moves the pointer toward the tooltip content; the trigger fires mouseleave; the tooltip disappears before the user reaches it.

The third: focus-only triggers. The tooltip appears on Tab focus but not on hover; or on hover but with no focus equivalent. Both directions need to work.

Failing examples

A CSS-only tooltip with no Escape handler and no hoverable region:

<span className="group relative">
  <InfoIcon aria-hidden="true" />
  <span className="absolute hidden group-hover:block">
    Helpful information goes here.
  </span>
</span>

A title attribute as a "tooltip":

<button title="Save your changes">
  <SaveIcon aria-hidden="true" />
</button>

Passing examples

A tooltip that handles all three rules — typically easier with a library that implements ARIA tooltip behaviour for you (Radix UI, Headless UI, Floating UI):

import * as Tooltip from "@radix-ui/react-tooltip";

<Tooltip.Provider delayDuration={200}>
  <Tooltip.Root>
    <Tooltip.Trigger asChild>
      <button aria-describedby="save-tip">
        <SaveIcon aria-hidden="true" />
        <span className="sr-only">Save</span>
      </button>
    </Tooltip.Trigger>
    <Tooltip.Content id="save-tip" sideOffset={4}>
      Save your changes (Ctrl+S)
      <Tooltip.Arrow />
    </Tooltip.Content>
  </Tooltip.Root>
</Tooltip.Provider>

Radix handles dismissal on Escape, keeps the tooltip open while the pointer is over it, and persists until focus or hover leaves.

Edge cases

title is not a tooltip. The browser's tooltip behaviour is inconsistent, the styling can't be controlled, and screen-reader support is patchy. Use a real tooltip primitive.
Error and validation messages that appear next to a field on blur are not "content on hover or focus" — they don't disappear when focus leaves. They fall under 3.3.1.
Dropdown menus and disclosure widgets activated by click aren't in scope — those are not hover/focus reveals.
Mobile doesn't have hover; the criterion targets desktop/pointer use. Mobile equivalents must use tap and a discoverable trigger.
Tooltips that contain interactive content (links, buttons) need to be navigable by keyboard. Use a popover, not a tooltip.

How Jeikin handles this

axe-core flags title attributes used as the only accessible name on interactive elements. The richer behaviour — does pressing Escape dismiss, does the tooltip persist on hover — needs guided review. The dashboard records each tooltip pattern with a checklist for the three requirements; libraries with known-good ARIA behaviour are recorded once and reused as evidence.