Tooltip-only required information

Problem Context

• The hidden content is needed to complete a field, understand eligibility, choose an option, avoid a fee, meet a deadline, satisfy a document rule, or recover from a blocked control.
• The implementation uses a question-mark icon, native title attribute, aria-describedby tooltip, hover bubble, focus bubble, disabled-control tooltip, chart cell tooltip, or compact label tooltip as the only explanation.
• Users may be on touch devices, keyboard-only navigation, screen readers, high zoom, slow reading, switch control, or reduced pointer precision.
• The tooltip closes on blur, pointer out, Escape, scroll, validation rerender, viewport collision, route change, or mobile tap.

Selection Rules

• Flag this anti-pattern when the tooltip content is necessary to complete the task correctly or avoid a harmful outcome.
• Use visible helper text when users need the requirement while typing or selecting.
• Use inline message when the requirement is contextual feedback, validation recovery, warning, or a local next step.
• Use disclosure details when the information is optional but longer than a short tooltip and should stay in page flow after opening.
• Use popover when users intentionally open richer anchored help, examples, or light controls and can keep the surface open while acting.
• Use tooltip only when the content is short, noninteractive, supplemental, and safe to dismiss without changing task success.
• Open or reveal hidden required help automatically during validation recovery if it was optional before the error.
• Do not rely on native title attributes for required information.
• Do not attach the only explanation to a disabled native control that keyboard users cannot focus.
• Do not make users memorize a tooltip before moving to the field, checkbox, upload control, payment field, or table row that needs it.

Required States

• Default state with the requirement visible, summarized, or explicitly openable before users act.
• Tooltip-supplement state where the tooltip repeats or clarifies but is not the only copy.
• Keyboard path where Tab reaches the field and requirement without requiring hover.
• Touch path where the same required content is visible or intentionally openable.
• Screen reader path where the requirement is announced and can be revisited in normal reading order.
• Validation recovery state where the exact missing or invalid requirement remains visible.
• Disabled or blocked action state with adjacent reason and next step.
• Details or popover state for longer examples that stay open while users compare or copy.
• High zoom or narrow viewport state where helper text wraps without overlapping the field.
• Tooltip expired or dismissed state where required content is still present elsewhere.

Interaction Contract

• Users can complete the task without reading a tooltip.
• If the tooltip disappears, every required rule remains visible or reopenable through an explicit control.
• Required content is available before validation, not only after failure, when the user needs it to avoid mistakes.
• Keyboard, touch, screen reader, and pointer users receive equivalent required information.
• The tooltip contains no focusable controls and never asks users to move focus into it.
• Disabled controls expose the reason and recovery path outside the disabled element.
• Validation messages quote the exact requirement users missed rather than referring back to hidden help.
• Long, structured, legal, or consequence-bearing content moves to inline text, disclosure, popover, page content, or dialog according to task severity.

Implementation Checklist

• Inventory every tooltip, title attribute, help icon, and aria-describedby bubble in the flow.
• Classify each item as supplemental or required for task success, safe choice, validation, eligibility, legal consequence, or recovery.
• Move required text into visible helper text, inline message, validation copy, details disclosure, or popover content.
• Leave tooltips only for short supplemental descriptions tied to triggers that already have names.
• Provide explicit touch and keyboard routes for any help that users must intentionally open.
• Show blocked-action requirements beside the disabled or unavailable action, not only on hover.
• Test blur, Escape, pointer out, scroll, zoom, validation rerender, mobile tap, screen reader reading order, and slow-reader timing.
• Confirm the task can be completed correctly after all tooltips are dismissed.

Common Generated-UI Mistakes

• Putting accepted document types only in a help-icon tooltip.
• Putting password rules only in a field-focus tooltip.
• Putting eligibility thresholds only in a hover card or tooltip beside a question.
• Using a disabled button tooltip as the only explanation for why users cannot continue.
• Relying on native title attributes for required field format.
• Putting legal terms, fees, deadline consequences, or consent scope only in a tooltip.
• Hiding chart values, table definitions, or required column meaning only behind pointer hover.
• Using aria-describedby to hide instructions that disappear before the user can apply them.

Critique Questions

• Could users complete the task correctly if every tooltip disappeared?
• Is any tooltip text required to answer, choose, pay, upload, consent, or recover?
• Can touch users and keyboard users reach the same information before acting?
• Does validation repeat the exact hidden requirement when users miss it?
• Should this content be visible helper text, inline message, disclosure details, popover, warning text, or validation copy?
• What happens when focus leaves the trigger, Escape closes the tooltip, the page scrolls, or the viewport is narrow?