A tooltip carries a surprising amount of failure for something so small. It appears on hover, so keyboard users never see it. It disappears the moment the pointer moves, so anybody reading it through magnification cannot get to it. And it covers the thing it was describing.
WCAG 2.1 added 1.4.13 Content on Hover or Focus at Level AA, largely for this pattern, and it sets three conditions. Before the conditions, though, W3C offers a piece of advice it does not usually offer. There are usually more predictable and accessible ways of adding content to a page, and authors are recommended to use them. That is the standards body suggesting you consider not building this at all, which is worth a moment before you carry on.
The Three Conditions
- Dismissible. A mechanism is available to get rid of the extra content without moving the pointer or the keyboard focus. Escape is the example W3C gives and it is an example rather than the definition, so a different mechanism can satisfy this too. It matters most under magnification, where somebody sees a fraction of the screen and a panel following the pointer sits on top of the thing they were reading.
- Hoverable. If hovering triggers it, the pointer can move onto the content itself without it vanishing. Long text, or a link inside it, is unreachable otherwise.
- Persistent. It stays visible until the trigger loses hover or focus, until the user dismisses it, or until its information stops being valid. No timeouts. This is the condition a tooltip that fades after three seconds breaks, and it is the one people leave out of the list.
Dismissible carries two exemptions worth knowing, because both save work. Content communicating an input error does not have to be dismissible, since it generally needs the user's attention or a fix. And content that does not obscure or replace anything meaningful, including the trigger itself, is outside the condition too. So a tooltip positioned over white space or over purely decorative background has discharged Dismissible by geometry. That is a free win and we never used to mention it.
Hoverable is the condition most implementations miss, and there is evidence for saying so rather than only an impression. W3C published exactly one failure technique for this criterion and it is about Hoverable, which is content shown on hover that cannot be hovered. The cause is almost always the same. The code hides on mouseleave, and the gap between the trigger and the tooltip fires it before the pointer arrives. The one sufficient technique covers all three conditions together.
Two things the criterion does not reach. A skip link revealed on keyboard focus is expressly outside it, because it presents no additional content. And modal dialogs are outside it too, since they take focus and are therefore not supposed to appear on hover at all.
The title Attribute, and What It Actually Fails
The title attribute is tempting because the browser draws something that looks right for free. The three conditions above do not reach it. The criterion excepts content whose visual presentation the browser controls and the author has not modified, and the standard names browser tooltips made with title as its example.
That is not a pass. It means this criterion is the wrong one to cite. What title does fail is 2.1.1 Keyboard, because the content it holds is reachable by hover and generally not by keyboard focus. Where title is a control's only accessible name, it also raises 4.1.2. Knowing which criterion applies is the difference between a finding that stands and one a developer knocks out in a sentence.
The practical case against it is separate from all of that and is enough on its own. It does not appear on keyboard focus in most browsers. It cannot be styled, so it cannot be made to meet a contrast requirement or be reached by a pointer. It disappears on a timer in some browsers. And screen reader support for it is inconsistent enough that you cannot rely on it being read at all, because in the name computation it is a last-resort fallback rather than a first choice. Put nothing in a title attribute that you would mind a user never seeing.
Wiring a Real Tooltip Up
A tooltip describes its trigger, and that connection has to be programmatic rather than visual. Before the list, one thing about the pattern itself. W3C's tooltip pattern is unfinished. It carries a note saying it does not yet have task force consensus, and there is no worked example published for it. That is the single most useful thing to know here, because it explains why every tooltip library disagrees with every other one, and why you should not expect to find a settled answer.
- Give the tooltip
role="tooltip"and an id. Be clear about what that buys. The role tells assistive technology what the thing is, and it is described as a supplement to the browser's own tooltip behavior. It specifies no behavior at all, so it does not discharge any of the three conditions. You can set the role correctly and fail all three. - Point at it from the trigger with
aria-describedby. That is what makes the announcement happen, since a tooltip is not a live region and says nothing by appearing. - Show it on hover and on focus. Hide it on blur and on Escape. Focus stays on the trigger throughout. A tooltip never takes focus itself.
- Never put a focusable control inside a tooltip. If people need to interact with the content, it is not a tooltip.
That last one needs a destination rather than a prohibition. Where the content holds a link or a button, W3C's own answer is a non-modal dialog, and the modern platform answer is a popover, which is non-modal by construction. What it is not is a dialog element used loosely. The HTML standard says outright that using dialog to represent a context menu, a tooltip or a popup listbox is non-conforming, which is exactly the mistake this advice exists to prevent.
Tooltip or popover?
A tooltip is a short label describing the thing it is attached to. No interactive content, appears on hover and focus, and never takes focus. A popover is real content that may contain controls, usually opens on a click, and behaves closer to a non-modal dialog. If somebody has to click something inside it, you are building the second one.
The Native Popover, and the Part Aimed at Tooltips
The popover attribute handles the top layer, light dismissal and Escape with no JavaScript, and it has worked across the major browsers since April 2024. In its ordinary state it is built around explicit invocation, so a click, which is why it does not replace the tooltip pattern on its own.
There is a part of the same family aimed directly at this page's problem, and it is worth watching even if you cannot use it yet. Interest invokers let a control show a popover when it is hovered or focused, with no script, and pressing Escape cancels the interest, which is the Dismissible condition handled by the browser rather than by you. There is a popover state named for exactly this case, and a CSS property for the delay before it appears and disappears. Availability is the open question, so treat this as the direction of travel rather than as something to ship today, and check current support before you build on it.
Do Not Hide Essential Information
Password rules, format requirements, pricing caveats and delivery exclusions do not belong behind a hover. They belong in visible help text near the field, tied to it so it is announced with the control. A tooltip is for the thing that helps if you happen to find it, never for the thing somebody needs to finish.