A retail bank's mobile app shows an overdraft-fee tooltip ending in a 'See fee schedule' link; which users cannot reach that link, and what should replace the tooltip?
answer
- focus stays on the trigger
- it closes on the way there
- touch has no hover
- read as a description, not a control
- an explicit, non-modal container
basics
~20 sKeyboard, switch and screen-reader users cannot move focus into a tooltip, and touch users cannot hover, so most people never reach the link. Replace it with inline text and a link, or a popover opened by an explicit tap.
solid answer
~50 sA tooltip's contract is that **focus stays on the trigger** and the tooltip closes when hover or focus leaves. So a keyboard or switch user tabs to the info icon, sees the tooltip, presses Tab — and focus moves past it as it closes. A screen-reader user hears the text as a description of the icon, with no link to activate. A touch user has no hover, and a tap may activate the icon's own action. Only a careful mouse user, moving onto the tooltip without it closing, can click it. The fix depends on the content: a fee this important belongs **inline** under the balance with a normal link; if it must stay behind an icon, use a **popover** — the Authoring Practices tooltip page itself suggests a non-modal dialog for focusable content — that opens on tap, can take focus, closes on Escape or a tap outside, and returns focus to the icon.
go deeper
Recall that focus never enters a tooltip and phones have no hover, so nothing interactive can live in one.
Walk through each user group's experience of the link, then explain the popover's contract: explicit open, reachable content, Escape, focus back to the trigger.
Show how you would diagnose and fix this across an app: audit every tooltip, choose inline text, toggletip or popover per case, and close the gap in the component.
Frame the fix as a system guarantee — the tooltip accepts text only — and weigh restricting component flexibility against repeated accessibility defects.
## Why a link in a tooltip fails A **tooltip** in a design system is a small popup of supplementary text that appears when its trigger is hovered or focused. The WAI-ARIA Authoring Practices tooltip page — which is labelled work in progress, without task force consensus, so treat it as guidance — says that tooltip widgets do not receive focus, that focus stays on the triggering element while the tooltip shows, and that a popup containing focusable elements can be made as a **non-modal dialog** instead. Everything that goes wrong with a link inside a tooltip follows from those sentences. | User | What happens with the link | |---|---| | Keyboard or switch user | Tabs to the info icon; the tooltip appears; the next Tab moves focus past it and the tooltip closes. The link is never in the focus order. | | Screen-reader user | Hears the tooltip text as the icon's description; there is no link to navigate to, because a description is read as text. | | Touch user | Has no hover. A tap may activate the icon, or show the tooltip briefly, but there is no reliable way to tap inside it. | | Magnifier user | May see only part of the tooltip, and if it is not hoverable it closes before they reach the link. | | Mouse user | Can reach it only if the tooltip is hoverable and they move onto it carefully. | In a retail bank's mobile app, the audience is overwhelmingly touch, so the fee schedule — information a customer may have a right to see — is effectively hidden. ## The contract the tooltip broke A tooltip holds **short text that is safe to miss**. The fee schedule link breaks both halves: it is interactive, and the information behind it matters. The component did what it was designed to do; it was the wrong component. ## Replacement options 1. **Inline text and a link.** 'An overdraft fee may apply. See fee schedule' directly under the balance. Nothing to open, nothing to miss — the best option for information this important. 2. **A toggletip** if the explanation is short and needs no link: an info button that reveals the text on tap and hides it on a second tap, Escape or a tap elsewhere. 3. **A popover** if the explanation must stay behind the icon and needs the link: a non-modal panel opened by an explicit tap or key press. ## The popover's behaviour contract - Opens on **explicit activation** of the trigger — tap, click, Enter or Space — never on hover alone. - The trigger exposes that it controls a popup and whether it is currently open. - When it opens, the link is **reachable**: focus either moves into the popover or the popover comes next in the focus order. - It **stays open** until the user closes it: a close control, Escape, or a tap or click outside. - On close, focus goes **back to the trigger**. The Authoring Practices state this for dialogs; popovers commonly follow the same convention so users keep their place. - It is **non-modal**: the rest of the screen stays usable, and it does not trap focus. Blocking the screen would make it a modal dialog, a different component. ## Preventing it across the system - The tooltip specification says **plain text only**, with the reason, and the component accepts only text content so a link cannot be passed in. - The documentation shows the popover and toggletip side by side with the tooltip, so teams find the right one when they reach for 'a little info bubble'. - An audit lists every tooltip in the app and flags any holding links, controls, or information a user must see. - Manual testing covers the path that exposed this bug: reach the link by keyboard alone, by screen reader alone, and by touch alone. - Content design reviews tooltip copy like any other interface text, because a tooltip that keeps growing is usually a sign the information belongs on the screen. The lesson for an interview answer is the order of the diagnosis: name who cannot reach the link and why, name the contract the component broke, and only then choose the replacement by how important and how interactive the content is.
- The team argues mouse users can click the link, so it works for most people. How do you answer?In a mobile banking app most users are on touch, where the link is unreachable, and keyboard, switch and screen-reader users cannot reach it on any device. A control that only careful pointer users can activate fails the majority here, and it fails the users least able to find a workaround.
- Should focus move into the popover when it opens, or stay on the trigger?Both are workable if the content is reachable. Moving focus into it suits a popover whose purpose is its content, like a link or a short form; keeping focus on the trigger with the popover next in the focus order suits a lighter panel. What is not acceptable is a popover whose content can be reached only by pointer.
saying these in an interview costs you the question
- A link in a tooltip is fine because mouse users can hover onto it.
- Screen-reader users can reach the link because the tooltip text is read aloud.
- Making the tooltip stay open longer solves keyboard access to the link.
- Replacing the tooltip with a modal dialog is the only accessible option.
- A popover should open on hover so it feels as light as a tooltip.