What belongs in a tooltip, and what should stay visible?
A small information icon beside a pricing card can make an interface look tidy. But if a visitor only discovers an important condition by hovering over that icon, the apparently simple screen offers an incomplete explanation. Good tooltip design begins by deciding how important the information is. This article examines brief help attached to a particular field or term, rather than the longer sections handled by an accordion or a detailed service page.
Keep decision conditions in visible text
Imagine an original service-card example stating “Two revision rounds”. A short explanation of the term may work as supplementary help. But whether extra revisions are assessed separately, which file formats are delivered and what falls outside the scope directly affect the choice. Do not leave those conditions only inside an information bubble. Read the card with all help icons removed: can a visitor still explain what is included and under which conditions? If not, revisit the content hierarchy.
Explain one term briefly and locally
Our example could define a revision round as feedback collected into one list for review. This is sample wording, not a claim about every agency or agreement. If the explanation grows into paragraphs, requires exceptions or introduces another action, a small bubble may be the wrong container. Use an inline explanation or a fuller service page. Supplementary help should not become a second layer of writing that repeatedly compensates for unclear primary content throughout the interface.
Inspect the official behaviour example
The W3C explanation of content on hover or focus describes dismissibility, hoverability and persistence for the custom content it covers, alongside exceptions. The practical lesson is to design reading and dismissal as well as appearance. Where a popup obscures meaningful content, consider a way to dismiss it without moving focus. Passing this particular check does not establish accessibility for the entire page; it addresses one aspect of the interaction.
Try a separate task on a touch screen
On a phone, ask a visitor to understand the service scope, close the explanation and return to the primary action. Watch for accidental taps, content extending outside the viewport or an unclear closing mechanism. Do not assume that a mouse interaction automatically works well on a phone. Specify the behaviour of details opened by a tap separately. If the information is important, a strong design choice may simply be to show it from the start instead of adding a more elaborate interaction.
Plan for the editor’s longer explanation
A three-word term today may acquire a two-sentence explanation tomorrow. Give editors a purpose for brief help and a destination for longer content, rather than only a character limit. Review Turkish and English with real text in the same available width. When a service condition changes, updating only one language’s bubble can create a mismatch. Assign ownership across visible card conditions, supplementary help and the full service page so the different pieces remain consistent after publication.
Write acceptance around finding information
Replace “the icon works” with a concrete review task: explain the package scope, find the meaning of a term and reach the enquiry action. Try it with keyboard, mouse and phone. Inspect the focus indicator and whether the explanation covers information needed for the task. This part of a website design project combines content and interaction. For the main package explanation, see the service pricing page guide; a small bubble cannot replace a missing definition of the service itself.
Frequently asked questions
Is using an information icon a mistake?
No. It can support short secondary explanations. Avoid making essential scope or decision conditions depend entirely on discovering that interaction.
Is automatically closing the bubble enough?
Do not guess the reader’s required time. Evaluate opening, reading, dismissal and return to the task with realistic content and different input methods.