The Little 'i' Icon Problem: Why Tooltips Trip Up Real Users

You have seen it a thousand times. A small circle with a lowercase “i” or a question mark sits next to a form field, a price, or a setting. You hover over it, a little box pops up explaining what the field means, and you move on. It feels like a helpful, polished touch.

For a lot of your customers, that little icon is a dead end.

Tooltips — those small pop-up boxes that appear when you hover over an icon or a word — are one of the most common accessibility failures on otherwise modern, well-designed websites. They fail quietly. Your site looks fine. Your designer is happy. Your automated scanner might not even flag it. But a customer using a keyboard, or a screen reader, or a phone, hits the same icon and gets nothing — or gets something so broken it actively makes the page harder to use.

This article is for the non-developer: the business owner, the marketer, the person who manages the website but does not write the code. You do not need to understand JavaScript to find this problem. You need to know what to look for and how to describe it to whoever fixes it.

Why tooltips matter more than they look

Tooltips usually hold information people actually need. “What format should this date be in?” “What does this fee cover?” “Why do you need my phone number?” When that information is locked inside a tooltip that only works one specific way, anyone who interacts with the page differently is excluded from it.

And tooltips show up in exactly the places where being excluded hurts most: checkout flows, sign-up forms, pricing tables, password requirements, and account settings. These are the high-stakes moments where a confused customer abandons the cart or gives up on the form. If the explanation they needed was trapped in an inaccessible tooltip, you did not just fail an accessibility checkbox — you lost a sale.

There is a legal dimension too. Under the Americans with Disabilities Act in the United States and the European Accessibility Act in the EU, customer-facing websites are expected to be usable by people with disabilities. The relevant standard, WCAG 2.2, has a specific success criterion — 1.4.13, “Content on Hover or Focus” — that exists almost entirely because of how often tooltips and pop-ups are built badly. When a tooltip cannot be reached, cannot be dismissed, or disappears the moment you try to read it, that is a documented WCAG failure, and it is the kind of thing that turns up in accessibility complaints and demand letters. (None of this is legal advice — talk to a qualified attorney about your specific situation.)

The three ways tooltips break

Tooltips fail in a few predictable ways. Once you know them, you will start spotting them everywhere.

1. They only respond to a mouse hover

This is the big one. Many tooltips are programmed to appear only when a mouse cursor hovers over the icon. That sounds reasonable until you remember that a huge number of people do not use a mouse.

People who navigate by keyboard — because of a motor disability, a temporary injury, or just personal preference — move through a page using the Tab key. If the info icon cannot receive keyboard focus, they can never trigger the tooltip. The information simply does not exist for them.

And it is not only keyboard users. There is no “hover” on a touchscreen. When someone taps that icon on their phone, a hover-only tooltip either does nothing or flickers and vanishes. Given that most small business websites get the majority of their traffic from phones, “works on hover” often means “broken for most of your visitors.”

2. The icon has no real label

Screen readers — the software blind and low-vision users rely on — read the page aloud. When they reach an icon, they announce whatever label the icon has been given in the code. The problem is that decorative icons frequently have no label at all, or a useless one.

A blind user tabbing through your form might hear “button” with no further explanation, or hear nothing, or hear the file name of an image like “info-circle-2.svg.” None of that tells them there is helpful information available, let alone what it says. Even if the tooltip content is technically in the code, if the icon that opens it is unlabeled, the user has no idea it is there to be opened.

3. The tooltip is impossible to read or dismiss

WCAG 1.4.13 lays out three things a well-behaved tooltip must do, and badly built ones routinely fail all three:

  • Dismissable. You must be able to make the tooltip go away (usually with the Escape key) without moving your mouse or your focus. Imagine a tooltip that pops up and covers the very form field you are trying to fill in, and there is no way to close it. That actually happens.
  • Hoverable. You must be able to move your pointer onto the tooltip itself — for example, to read a longer explanation or click a link inside it — without it disappearing. Tooltips that vanish the instant your cursor leaves the icon fail this, and they are maddening for people with low vision who are zoomed in and need a moment to read.
  • Persistent. The tooltip should stay visible until you move away, dismiss it, or its information is no longer valid. It should not time out and disappear on its own while you are still reading. People who read slowly, including many users with cognitive disabilities, need the content to stay put.

How to test your own tooltips in five minutes

You do not need any special software. You need your keyboard and a little patience. Pick a page on your site that has info icons — a form or a pricing table is ideal — and try this.

The keyboard test. Click once at the very top of the page, then put your mouse down and do not touch it again. Press the Tab key repeatedly to move through the page. Watch for a visible outline or highlight that jumps from link to link and field to field. When you get near an info icon, does the highlight ever land on it? If yes, do you see the tooltip appear? If the focus skips right over the icon, or lands on it but no tooltip shows, you have found a hover-only tooltip. That is failure number one.

The Escape test. If you did manage to make a tooltip appear, try pressing the Escape key. Does it close? Now try this with your mouse: hover to open a tooltip, then slowly move your cursor onto the tooltip box itself. Does it stay open, or vanish before you can read it? A tooltip that will not let you move onto it is failing the “hoverable” rule.

The phone test. Open the same page on your phone. Tap each info icon. Does anything useful happen? Can you read the full message and then make it go away? If tapping does nothing, or the box flashes and disappears, your tooltips are failing your mobile visitors — which, again, is probably most of them.

The zoom test. On your computer, press Ctrl and the plus key (Cmd and plus on a Mac) several times to zoom the page to around 200 percent. Now hover over an info icon. Does the tooltip appear fully on screen, or does part of it get cut off at the edge? Zoomed-in users need the content to fit and stay readable.

If you want to go one step further and hear what a blind visitor experiences, you can turn on the screen reader already built into your computer and listen as you tab to an info icon. Our guide on how to test your website with VoiceOver walks through that without any coding.

What “fixed” looks like

You do not have to know how to build the solution, but it helps to know what good looks like so you can recognize it — and ask for it.

A well-built info tooltip can be reached and opened with the keyboard, not just the mouse. The icon has a clear text label so a screen reader announces something useful like “More information about billing address.” The pop-up can be dismissed with the Escape key, you can move onto it to read it without it vanishing, and it stays up until you are done. On a phone, tapping the icon opens the information and tapping again or tapping elsewhere closes it.

There is also a simpler answer that is often better: skip the tooltip entirely. A surprising amount of tooltip content does not need to be hidden in the first place. If a form field needs a date in a specific format, just put “MM/DD/YYYY” as visible helper text under the field. If a fee needs explaining, write one short sentence beneath it. Visible text that is always on screen works for everyone — mouse, keyboard, touch, and screen reader alike — and it removes an entire category of bugs. The best tooltip is frequently the one you decided you did not need.

When hidden help genuinely makes sense — because the explanation is long, or only some users want it — that is when a properly built, keyboard-accessible, screen-reader-labeled tooltip earns its place. The point is not that tooltips are evil. It is that a tooltip is a small interactive component with real accessibility requirements, and too many sites treat it as a purely visual decoration.

The bottom line

That little “i” icon is a tiny piece of your website, and it is easy to assume something so small could not cause real problems. But the information it holds is often exactly the information a confused customer needs to finish a form or complete a purchase. When the tooltip only works on hover, when the icon has no label, or when the box cannot be read or dismissed, you have quietly shut out keyboard users, screen reader users, mobile users, and anyone zoomed in to read.

The good news is that this is one of the easiest accessibility problems to find yourself. Tab through your forms. Tap your icons on your phone. Ask whether the information would be better off just visible on the page. You will likely catch in ten minutes what your scanner missed entirely.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.