In a design system, how does a tooltip differ from a popover, and what content is each allowed to hold?
answer
- describes, never does
- hover and focus vs explicit activation
- focus never enters a tooltip
- no hover on a touch screen
- interactive content means popover
basics
~20 sA tooltip is short supplementary text shown on hover or focus that never takes focus, so it holds no links, buttons or essential information. A popover opens on explicit activation, can take focus and may hold interactive content.
solid answer
~50 sA **tooltip** describes the element it belongs to — a short hint for an icon-only control, say — appears when that element is hovered or focused, and disappears when hover or focus leaves. Focus stays on the trigger, so nothing inside a tooltip can be reached by keyboard, and a touch screen has no hover at all; therefore a tooltip holds plain text only and nothing the user needs to finish the task. A **popover** opens because the user explicitly activated a trigger (tap, click, Enter or Space), stays open until dismissed, can receive focus, and may hold links, buttons or form controls. It is non-modal: the rest of the screen keeps working. Many systems add a **toggletip** between the two: an info button that shows a short explanation on tap, which is how 'What does APR mean?' should work in a mobile app.
go deeper
Recall the split: tooltip for short supplementary text on hover or focus, popover for anything interactive opened on purpose. Know that touch screens have no hover.
Explain the contracts beneath: where focus goes, how each closes, why focus never enters a tooltip, and where a toggletip fits between the two.
Show how you would audit an app's tooltips for essential or interactive content and move each into inline text, a toggletip or a popover.
Decide which overlay components the system offers at all, and how the spec stops teams from bending the tooltip into a popover.
## Two components, two contracts Both components show a small floating panel next to a trigger, which is why teams confuse them. Their **contracts** — what opens them, where focus goes, what they may contain — are different, and choosing the wrong one locks users out. A **tooltip** is a contextual popup that displays a description for an element; that is how the WAI-ARIA 1.2 specification defines the tooltip role. The WAI-ARIA Authoring Practices describe a tooltip pattern — marked on its own page as work in progress, without task force consensus — in which the tooltip appears when its trigger receives keyboard focus or pointer hover, does not itself receive focus, and closes on Escape or when hover or focus leaves. A **popover** is a non-modal floating panel opened by an explicit action. It can contain anything a small region of the screen can: text, links, buttons, a short form. Because it may contain focusable content, it must be reachable and closable by keyboard, pointer and touch alike. ## Side by side | Aspect | Tooltip | Popover | |---|---|---| | Opened by | Hover or focus on the trigger | Explicit activation: tap, click, Enter or Space | | Focus | Stays on the trigger | May move into the popover | | Content | Short plain text only | Text, links, buttons, small forms | | Closes when | Hover or focus leaves, or Escape | User dismisses: close control, Escape, tap outside | | On touch screens | No hover, so often never seen | Works the same as with a pointer | | Essential information? | Never | Allowed, though inline text is often better | ## What 'supplementary' means A tooltip's text must be **safe to miss**. The test for every tooltip in a spec: - Would a user who never sees it still complete the task? If not, the text belongs on the screen. - Does it repeat or expand something already visible, such as the name of an icon-only control? That is a good tooltip. - Does it contain anything to press, select or copy? Then it is not a tooltip. - Is it more than a sentence or so? Long text in a tooltip is hard to read before it disappears. ## Touch changes the answer In a **retail bank's mobile app**, most users never hover — a finger has no hover state. A hover tooltip on a savings account's 'AER' label would simply never appear for them, and on some platforms a long press is not a discoverable way to reveal it either. That is why mobile design systems lean on: 1. **Inline text** for anything important — the rate explained in a line under the figure. 2. A **toggletip**: an explicit info button that shows a short explanation when tapped and hides on a second tap, Escape, or a tap elsewhere. It is text-only like a tooltip but opened like a popover. 3. A **popover** when the explanation needs a link or an action, such as 'Compare accounts'. On native platforms, a built-in tooltip usually appears after a long press on an icon-only control and shows its name — which is exactly the supplementary role, not a home for explanations. ## Choosing in a spec 1. Is the content interactive? Use a popover. 2. Is it essential to the task? Put it inline on the screen. 3. Is it a short explanation users ask for? Use a toggletip. 4. Is it the name or a brief hint for a control that already has an accessible name? A tooltip is fine. ## Common mistakes - Putting a 'Learn more' link inside a tooltip. - Hiding the only explanation of a fee or a rate behind hover. - Opening a popover on hover, so it vanishes when the pointer moves toward its buttons. - Treating a popover as a modal dialog and blocking the page — that is a different component with its own contract. - Using a tooltip to repeat a label that is already visible, which adds noise for pointer users and a duplicate announcement for screen-reader users. - Letting one team's tooltip open on focus and another's on hover only, so the same component behaves differently across screens. A design system prevents most of these by documenting the three components on one page with the decision list above, so a designer reaching for 'a little info bubble' sees all three options and the reason for each.
- Is a tooltip acceptable as the only name of an icon-only button?The visible tooltip text can match the name, but the button still needs an accessible name of its own, exposed programmatically, because the tooltip is not shown on touch and may not be read in every context. The tooltip then adds a visual label for pointer and keyboard users on top of a name that already exists.
- What does a toggletip add that neither a tooltip nor a popover gives you?It keeps the tooltip's limit — short text only — but uses the popover's trigger: an explicit tap or key press on an info button. That makes the explanation reachable on touch screens and by keyboard without the full focus handling an interactive popover needs.
saying these in an interview costs you the question
- A tooltip is fine for a 'Learn more' link as long as it is small.
- Tooltips work on phones because a long press is the same as hover.
- A popover and a modal dialog are the same component with different sizes.
- Important warnings can live in a tooltip to keep the screen clean.
- Popovers should open on hover so users do not have to tap.