Why my tooltip doesn't show on mobile — three causes and how to fix each

Familiar symptom: on a laptop you hover the little question-mark icon and the tooltip pops up, all good. Open it on a phone — nothing. Or worse: it appeared from a stray tap and now hangs there until you poke somewhere else.

It's almost always one of three causes. Most common first.

Cause 1. The tooltip hangs off hover, and a finger can't hover

This is nine cases out of ten. The tooltip is shown via :hover, but a touchscreen has no "cursor is over the element" state — only "a touch happened" and "no touch".

MDN documents what browsers actually do, and it's honest: on touchscreens :hover may never match, may match only for a moment after the touch, or may keep matching until the user touches another element. Which is why you get both symptoms — "nothing shows" and "it's stuck".

How to check. Open DevTools, switch to device mode and disable mouse emulation — or just grab a phone and tap the icon twice: if the tooltip only appears on the second tap, or won't go away afterwards, this is you.

How to fix. Stop treating hover as the only way to open it. There's a media query that asks the device directly whether it can hover, and it's been supported everywhere for years:

@media (hover: hover) and (pointer: fine) {
  .hint:hover .tip { display: block; }
}

On everything else the tooltip must open on tap or focus — which means the trigger has to be a real button:

<button type="button" aria-describedby="tip-1">What's this?</button>
<span id="tip-1" role="tooltip" hidden>Card number — 16 digits, no spaces</span>

A button gets you the keyboard for free: Tab opens it too.

Cause 2. It isn't a tooltip — it's the title attribute

Second most common: the markup has title="...", which on a desktop behaves like a tooltip. On a phone it doesn't. Browsers on touch devices simply don't show it.

MDN puts it bluntly: using title is highly problematic for people on touch-only devices, people navigating by keyboard, people using screen readers or magnifiers, and people with fine motor impairments. So this isn't "a mobile bug" — it's an attribute you can't put meaning into at all.

How to check. Search your code for title= on icons and links. If the tooltip text lives there, you found it.

How to fix. Decide how important the text is:

• Needed to complete the action (phone format, what's included in a plan) — don't hide it at all. Put it under the field as plain text. That hint never disappears and works for everyone — same logic as in placeholder vs label.
• Nice-to-have — move it into a real element with a button trigger, as above.

Cause 3. The tooltip exists, but a container clips it

Rarer and more annoying: the element is in the DOM, the styles applied, and still nothing on screen. The culprit is a parent with overflow: hidden (a card, a slider, a modal), a low z-index, or a tooltip that slid off the right edge of a narrow screen.

How to check. Select the tooltip element in DevTools and look at its box and coordinates. The classic tell is a non-zero size positioned off-screen, or a visible area of zero pixels. If the styles never applied at all, that's a different story — covered in why your CSS isn't working.

How to fix. Don't fight the parent's overflow — take the tooltip out of it. Modern browsers have a built-in mechanism for exactly this:

<button popovertarget="tip-2">What's this?</button>
<div id="tip-2" popover>We charge $19 right after you confirm</div>

An element with the popover attribute paints above everything and ignores the parent's overflow.

Three rules so you never come back to this

The WCAG accessibility standard (success criterion 1.4.13) asks exactly three things of content shown on hover or focus — handy as a checklist:

1. Dismissible. You can get rid of it without moving the pointer or changing focus — Esc, for instance.
2. Hoverable. You can move the mouse onto the tooltip itself and it won't vanish on the way.
3. Persistent. It stays until the trigger is removed or the person dismisses it.

The third point explains why "show it for two seconds, then hide" is a bad idea: people read at different speeds, and auto-hiding breaks exactly the people who needed the hint most.

The takeaway is simple: a hint you can't complete the action without must not live in hover. Hover is a bonus for mice. Anything mandatory goes on the screen as plain text, by the microcopy rules. And if the rest of your layout also misbehaves on phones, start with the responsive checklist.

Why didn't device mode in my browser catch this?

Because DevTools device emulation changes the viewport and the user agent, but your mouse is still a real mouse. The cursor still hovers, :hover still fires, the tooltip still pops — and the bug stays invisible until the first real phone. That's exactly how these things reach production: they don't reproduce on the developer's machine. Turn on touch emulation in DevTools, or just open the page on your phone — two minutes is enough.

Can I just show the tooltip on tap?

Yes, and that's the right path — but the trigger must be a real button, not a div with a handler. Otherwise it won't open from the keyboard and won't be announced by a screen reader.

Why does the tooltip get stuck after a tap?

That's the :hover behaviour on touchscreens: the hover state sticks to the element until something else is touched. The hover: hover media query fixes it — without it, any hover effect on a phone behaves unpredictably.