Accessible Tooltips and Info Icons: What WCAG 1.4.13 Requires
Quick answer: WCAG 1.4.13 Content on Hover or Focus
(Level AA, WCAG 2.1) applies whenever hovering or focusing an element makes extra content appear
and disappear — the exact shape of a “?” or ⓘ info-icon tooltip. It requires that content be
dismissible (closeable without moving the pointer or focus), hoverable (the pointer can
move onto the tooltip without it vanishing), and persistent (stays visible until dismissed or
the trigger is removed, not on a fixed timer). A tooltip built only on the native HTML title
attribute meets none of these reliably — the most common failure mode on e-commerce sites.
This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA is a technical-practice standard, not a legal determination — consult qualified counsel for legal risk questions.
What the success criterion actually says
SC 1.4.13’s own text, quoted directly from the Understanding doc: “Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true.” Three conditions follow:
- Dismissible — “A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content.” In practice: an Escape-key handler that doesn’t require the user to move away from what they were doing.
- Hoverable — “If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing.” A tooltip that vanishes the instant the mouse crosses from the icon toward the popup text fails this.
- Persistent — “The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.” A tooltip that auto-hides after a fixed two- or three-second timer, regardless of whether the user is still reading it, fails this condition specifically.
There’s one exception, also quoted directly: “The visual presentation of the additional content is
controlled by the user agent and is not modified by the author.” That’s what exempts a plain
browser-rendered title tooltip from the criterion itself — the browser controls its timing and
appearance, not the site. It isn’t a statement that native title tooltips are a good accessible
pattern, which is a separate problem covered below.
The Understanding doc names the covered content directly: “custom tooltips, sub-menus, and other nonmodal popups” that “may obscure other content when they are displayed.” Its Intent section ties the rule to low-vision users at high screen-magnification zoom, who lose surrounding context when a hover popup covers part of the page and disappears before they can pan to read it, and to users with limited fine motor control who can’t hold a mouse perfectly still over a small trigger.
Why the title attribute alone doesn’t solve this
The most common tooltip pattern on e-commerce sites is still <span title="Sizes run small — order one size up">, relying on the browser’s native title tooltip. It’s exempt from SC 1.4.13’s own
scope, but it independently fails a more basic bar: it’s often not usable at all. Per
MDN’s own documentation for the title global attribute,
the attribute is “highly problematic” for people using touch-only devices, people navigating with
keyboards, and people using assistive technology, “due to inconsistent browser support, compounded
by the additional assistive technology parsing of the browser-rendered page.” MDN’s own
recommendation is direct: “If a tooltip effect is desired, it is better to use a more accessible
technique” than title.
On a touchscreen there’s usually no hover state at all, so a title tooltip may never appear no
matter how long a shopper presses the icon. On desktop, a keyboard user tabbing through the page
gets no guarantee the browser shows the title text on focus the way it does on hover — behavior
varies by browser. And a screen reader that does announce a title value typically reads it once,
with no way to “re-open” it or interact with a link inside it.
The accessible pattern: WAI-ARIA’s Tooltip role
The WAI-ARIA Authoring Practices Guide’s Tooltip pattern
lays out the structure that satisfies 1.4.13. The trigger is a real, focusable element (a
<button>, not a <span>/<div> with a click handler bolted on) referencing the tooltip’s id via
aria-describedby. The tooltip container uses role="tooltip" and is not focusable itself —
per the pattern, “focus stays on the triggering element while the tooltip is displayed.”
The tooltip appears “when the element receives keyboard focus or the mouse hovers over it,” typically after a short delay. Escape dismisses it — satisfying the dismissible condition without forcing a keyboard user to tab away. A focus-triggered tooltip closes on blur; a hover-triggered one “remains open as long as the cursor is over the trigger or the tooltip itself” — satisfying the hoverable condition.
Worth flagging: the APG’s own tooltip page states, “This design pattern is work in progress; it does not yet have task force consensus” — treat it as the best current documented baseline, and manually test dismiss/hover/persist behavior yourself rather than assuming a component library’s “Tooltip” export already gets it right. Plenty of UI-library tooltips predate 1.4.13 (published with WCAG 2.1 in 2018) and were built purely as a visual hover effect.
Where this shows up on e-commerce pages
The info-icon tooltip is one of the most common small components on a product or checkout page, attached to whatever doesn’t fit in the main copy: a size-guide icon next to a size selector (“sizes run small, order one size up”), a material/ingredient call-out on an apparel or cosmetics page, a financing explainer next to a “4 payments of $X” line at checkout, a gift-wrap/personalization detail, or a shipping-estimate caveat next to a delivery date. It’s the same underlying pattern — compact trigger, popup with more detail — repeated across a page, which makes it worth fixing once as a shared component rather than five slightly different ad-hoc ways.
A minimal accessible implementation
<button type="button" class="info-trigger" aria-describedby="size-tooltip">
<span class="visually-hidden">More information about sizing</span>
<svg aria-hidden="true" focusable="false"><!-- "i" icon --></svg>
</button>
<div role="tooltip" id="size-tooltip" class="tooltip" hidden>
Sizes run small on this style — we recommend ordering one size up.
</div>const trigger = document.querySelector('.info-trigger');
const tooltip = document.getElementById('size-tooltip');
const show = () => tooltip.hidden = false;
const hide = () => tooltip.hidden = true;
trigger.addEventListener('mouseenter', show);
trigger.addEventListener('focus', show);
trigger.addEventListener('mouseleave', (e) => {
if (!tooltip.contains(e.relatedTarget)) hide();
});
trigger.addEventListener('blur', hide);
tooltip.addEventListener('mouseleave', hide);
document.addEventListener('keydown', (e) => {
if (e.key === 'Escape' && !tooltip.hidden) hide();
});Three details in that snippet do the actual work: the trigger is a real <button> with its own
accessible name (the visually-hidden span) independent of the tooltip content, satisfying SC
4.1.2 Name, Role, Value — a
screen reader user needs to know what the button does before activating it, not just what the
tooltip says afterward. The mouseleave check against relatedTarget keeps the tooltip open if
the pointer moves from the trigger onto the tooltip box, instead of hiding it the instant the
cursor leaves the icon (the hoverable condition). And the Escape handler provides dismissal without
forcing the pointer or focus to move first (the dismissible condition).
Can an automated scanner catch this?
Only partially. A rule engine can flag a role="tooltip" element with no accessible relationship
to its trigger, or an icon-only button with no accessible name — both structural checks. What it
can’t do is drive a mouse from the trigger onto the tooltip and confirm the content doesn’t
disappear mid-move, hold focus and check Escape actually closes it, or catch a fixed-timeout
auto-hide. All three of SC 1.4.13’s conditions are behavioral — exactly the category that needs a
person testing keyboard and hover interaction directly, not just a scanner report.
FAQ
Does SC 1.4.13 apply to a plain browser title tooltip?
No — the Understanding doc’s own exception covers content “controlled by the user agent and not
modified by the author,” which describes a native title tooltip. That doesn’t make title a
good mechanism, though; see above on why MDN calls it “highly problematic” for touch, keyboard,
and assistive-tech users, independent of this criterion.
Does this still apply if the tooltip is just plain text, no links? Yes — a screen-magnifier user at high zoom still needs time to read plain text before it disappears, and a keyboard user still needs a way to dismiss it without tabbing past it. Simpler content reduces how much can go wrong in the build, not the requirement itself.
Is title ever an acceptable fallback if a proper tooltip is too much to build?
Only as a non-essential, mouse-only hint — never as the sole path to information a shopper needs
to complete a purchase decision (sizing, financing terms). If the content gates a buying decision,
it needs a keyboard- and touch-reachable path; even a simple expand/collapse disclosure next to the
icon is more robust than a hover-only title.
Get a human-reviewed audit, not just a scan
A scanner can catch a missing accessible name on a tooltip trigger. It can’t verify the tooltip stays open when a mouse moves onto it, or that Escape dismisses it — manual, interaction-level checks. Quietramp’s audits pair an automated scan with exactly that kind of manual review, delivered as a prioritized, developer-actionable PDF report. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.
This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA does not resolve ADA or any other legal compliance question, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.
This article was drafted with AI assistance and reviewed by a person for accuracy before publication.