presentation form · Hover and contextual information
Hover Card
A richer preview of a referenced person, place, or object, revealed from its link or trigger on hover and focus.
Decisive boundary
If the surface exists mainly to operate controls, use a Popover.
Definition and intent
What is a Hover Card UI pattern?
Use the behavior, not the silhouette
A richer preview of a referenced person, place, or object, revealed from its link or trigger on hover and focus. The term is used here as a presentation form that describes placement or motion without deciding every semantic behavior. That distinction prevents a visual resemblance from silently deciding focus, keyboard, modality, or dismissal behavior.
Preview a referenced object without forcing navigation away from the current context. A good implementation preserves that job while making the trigger, open state, close path, and responsive behavior observable to users.
Know when the label is wrong
The fastest way to identify a pattern is often to reject the nearest alternative. For Hover Card, the boundary is: If the surface exists mainly to operate controls, use a Popover.
Do not implement it as Tooltip for rich previews and Popover for control-heavy tasks. If those requirements describe the real task better, use the related pattern page or the full Hover and contextual information comparison before writing code.
Decision process
Decide before choosing a component
Record these requirements in plain language. A library component name is not a substitute for the contract.
Confirm the user job
Preview a referenced object without forcing navigation away from the current context.
Define opening and closing
Hover or focus on a link or object reference. Pointer and focus leave the trigger and preview, or Escape.
Specify access behavior
The trigger remains the primary focus anchor; preview content should not create a hidden keyboard trap. Must be available from keyboard focus, not pointer hover alone.
Reject the near miss
Tooltip for rich previews and Popover for control-heavy tasks.
Behavior contract
What must survive the build
- trigger
- Hover or focus on a link or object reference.
- dismissal
- Pointer and focus leave the trigger and preview, or Escape.
- modality
- Non-modal.
- focus
- The trigger remains the primary focus anchor; preview content should not create a hidden keyboard trap.
- keyboard
- Must be available from keyboard focus, not pointer hover alone.
- interactive
- Primarily preview content; keep actions limited and verify the chosen implementation supports them.
- persistence
- Temporary while the user explores the reference.
- placement
- Anchored near the referenced object.
- mobile
- Provide a tap or direct navigation alternative because hover is absent.
Failure modes
Common wrong builds
- Making the preview pointer-only.
- Adding a dense form.
- Replacing the destination link with the preview.
Observable checks
Verify the result
- Keyboard focus can reveal the preview.
- The original link remains usable.
- The card stays open while the pointer moves into it.
- Escape dismisses it.
- Mobile users have a tap-safe path.
Coding-agent handoff
Implementation brief template
Pattern: Hover Card Purpose: Preview a referenced object without forcing navigation away from the current context. Trigger: Hover or focus on a link or object reference. Dismissal behavior: Pointer and focus leave the trigger and preview, or Escape. Modality: Non-modal. Focus behavior: The trigger remains the primary focus anchor; preview content should not create a hidden keyboard trap. Keyboard behavior: Must be available from keyboard focus, not pointer hover alone. Interactive content: Primarily preview content; keep actions limited and verify the chosen implementation supports them. Placement: Anchored near the referenced object. Mobile behavior: Provide a tap or direct navigation alternative because hover is absent. Do not implement as: Tooltip for rich previews and Popover for control-heavy tasks. Acceptance checks: - Keyboard focus can reveal the preview. - The original link remains usable. - The card stays open while the pointer moves into it. - Escape dismisses it. - Mobile users have a tap-safe path.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Hover Card UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Hover Card in web UI?
A richer preview of a referenced person, place, or object, revealed from its link or trigger on hover and focus. In this reference set it is a presentation form that describes placement or motion without deciding every semantic behavior.
When should I use a Hover Card?
Preview a referenced object without forcing navigation away from the current context. The decisive boundary to confirm is this: If the surface exists mainly to operate controls, use a Popover.
What keyboard and focus behavior does a Hover Card need?
Must be available from keyboard focus, not pointer hover alone. The trigger remains the primary focus anchor; preview content should not create a hidden keyboard trap. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Hover Card behave on mobile?
Provide a tap or direct navigation alternative because hover is absent. Its modality is a separate requirement: Non-modal.
How do I verify a Hover Card implementation?
Start with observable checks: Keyboard focus can reveal the preview. The original link remains usable. The card stays open while the pointer moves into it. Then verify the remaining checks and compare the result with the linked source guidance.