UX Patterns Guide
UI + UX Disclosure And Attention Management standard

Hover card

Show a compact object preview on hover or focus, keep it anchored to the referenced object, include only high-value metadata and an explicit route to the full object, make the card hoverable and dismissible, and provide non-hover access for users who cannot use pointer hover.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users need to inspect object metadata before choosing whether to open a link, mention, file, row, issue, or reference.
  • The preview can be summarized in a compact read-only card.
  • The interface contains dense references where navigation for every inspection would be costly.
  • An explicit full-object route or equivalent non-hover access is available.

Avoid when

  • The content is only a short description that belongs in a tooltip.
  • The content includes forms, complex controls, destructive decisions, or multi-step work.
  • The preview is required for task completion and must remain visible.
  • The primary target environment is touch-only and no explicit alternative is provided.
  • The preview cannot stay anchored or correct as the list scrolls or updates.

Problem it prevents

Dense interfaces often contain links, mentions, files, issues, and references that users need to inspect before opening, but navigating away for every object slows comparison and short tooltips cannot carry enough context.

Pattern anatomy

What a strong implementation has to make clear

User need

A link, mention, row, file, issue, alert source, or relationship reference has useful preview metadata.

Pattern promise

Show a compact object preview on hover or focus, keep it anchored to the referenced object, include only high-value metadata and an explicit route to the full object, make the card hoverable and dismissible, and provide non-hover access for users who cannot use pointer hover.

Required state

Resting trigger state with visible or accessible object identity.

Recovery path

The card appears only on mouse hover.

Access contract

Do not rely on hover card content as the only source of required information.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Hovering or focusing @Maya Chen opens a card with avatar, role, local time, current project, recent activity, and View profile link.
  • A file reference opens a hover card with filename, owner, modified time, sync state, preview thumbnail, and Open file route.
  • A user focuses @Maya Chen, reads the profile preview, moves the pointer into the card without it closing, presses Escape, and focus remains on the mention.
  • A user scans issue links and the hover card waits briefly before opening, closes after a short delay, and never changes the selected issue or route.
Weak implementation

Vague, hidden, hard to recover from

  • A hover card contains a long editable form, delete buttons, filters, and settings controls.
  • Hovering a row shows a card for the previously hovered person, with no title or object identity.
  • The card disappears while the pointer travels from the mention into the preview.
  • A keyboard user opens a hover preview but cannot dismiss it without losing focus or tabbing through hidden controls.
UI guidance
  • Render a hover card as a compact preview visually tied to a link, mention, row, object chip, file, person, or chart mark, with a title, key metadata, optional thumbnail, recent activity, and a clear route to the full object.
  • Keep hover-card content preview-oriented and brief; do not turn it into a full popover workflow, command menu, form, tooltip label, or persistent details panel.
UX guidance
  • Use hover cards to help users inspect an object before navigating, especially in dense lists, mentions, dashboards, file browsers, issue trackers, and relationship-heavy interfaces.
  • Make opening, delay, pointer handoff, keyboard focus behavior, Escape dismissal, close delay, collision handling, and alternate access predictable so the preview helps exploration without trapping or surprising users.
Implementation contract

What the implementation must handle

States

  • Resting trigger state with visible or accessible object identity.
  • Pointer hover pending state with a short open delay to avoid flicker while scanning.
  • Open hover card state anchored to the current trigger.
  • Pointer bridge or hoverable state where moving into the card does not immediately close it.

Interaction

  • The card previews only the object represented by the current trigger.
  • The card opens on pointer hover and can also open on keyboard focus when the trigger receives focus.
  • Open and close delays reduce flicker without hiding the existence of the preview.
  • Users can move the pointer from trigger to card without losing the card.

Accessibility

  • Do not rely on hover card content as the only source of required information.
  • Make the trigger keyboard focusable and expose a usable name for the referenced object.
  • Support Escape dismissal when the card appears on focus or hover.
  • Keep pointer-triggered content hoverable so users can move into it without disappearance.

Review

  • What exact object does this hover card preview?
  • Is the preview useful before navigation, or would a normal link, tooltip, popover, drawer, or page be clearer?
  • Can users reach equivalent information without pointer hover?
  • Can users move from trigger to card, dismiss with Escape, and keep focus on the trigger?
Interactive lab

Inspect the states before you copy the pattern

Preview an object before navigating

Hover or focus @Maya Chen, move into the hover card without closing it, switch to the file preview, dismiss with Escape, verify focus return and full-object route, then compare hover-only, pointer-gap, stale-object, required-info, interactive-trap, and focus-loss failures.

Hover card
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Resting trigger state with visible or accessible object identity.

Keyboard / Access

Tab moves focus to the trigger and may open the hover card for the focused object.

Avoid Generating

Using a hover card as the only place for required instructions or validation help.
Evidence trail

Source-backed claims behind this guidance

Radix UI Hover Card

Radix UI - checked

Supports hover-card placement, collision, arrows, controlled state, and open or close delays.

Full agent/debug reference

Problem Context

  • A link, mention, row, file, issue, alert source, or relationship reference has useful preview metadata.
  • Users repeatedly compare objects before deciding whether to navigate, open a drawer, or switch context.
  • The preview can be summarized without requiring interaction, editing, or commitment inside the card.
  • The implementation can support pointer hover, keyboard focus, Escape dismissal, pointer handoff, delay timing, collision handling, and alternate access.

Selection Rules

  • Choose hover card when users need a richer preview of an object behind a reference before deciding whether to open it.
  • Use tooltip when the content is only a short noninteractive description of the trigger.
  • Use popover when users intentionally open a stable surface with controls, choices, links, or light editing that must remain available after pointer movement.
  • Use disclosure details when the explanation should stay inline and visible after users open it.
  • Use drawer or details panel when users need persistent side-by-side inspection, comparison, or actions while continuing work.
  • Use preview panel or page navigation when the preview requires large media, long reading, deep metadata, or durable state.
  • Use context menu or action menu when the surface is primarily a command list rather than a preview.
  • Do not use hover card for required instructions, validation help, destructive decisions, authentication, or primary task actions.

Required States

  • Resting trigger state with visible or accessible object identity.
  • Pointer hover pending state with a short open delay to avoid flicker while scanning.
  • Open hover card state anchored to the current trigger.
  • Pointer bridge or hoverable state where moving into the card does not immediately close it.
  • Keyboard focus state where the card can appear for the focused trigger and be dismissed with Escape.
  • Close delay state that prevents accidental disappearance while the user corrects pointer movement.
  • Collision or scroll-container state where the card flips, shifts, or closes instead of clipping or detaching.
  • Stale-object prevention state where a changed, removed, or re-rendered trigger closes or refreshes the card.
  • Touch or assistive-technology alternate route state with an explicit open link, profile route, or inline equivalent.

Interaction Contract

  • The card previews only the object represented by the current trigger.
  • The card opens on pointer hover and can also open on keyboard focus when the trigger receives focus.
  • Open and close delays reduce flicker without hiding the existence of the preview.
  • Users can move the pointer from trigger to card without losing the card.
  • Escape dismisses the card and keeps focus on the trigger.
  • Pointer out, blur, scroll away, or trigger removal closes the card after the defined delay.
  • The preview includes an explicit route to the full object when users need durable access.
  • The card does not contain primary workflows, destructive choices, or controls that require stable focus management unless it is promoted to a popover or dialog.
  • Required information is available outside the hover card.
  • The card does not update the selected object, navigate, submit, or commit changes simply by opening.

Implementation Checklist

  • Define the object type, trigger identity, preview fields, and full-object route before designing the card.
  • Set open and close delays that fit dense scanning without causing flicker or sluggishness.
  • Keep the hover card title, metadata, status, activity, and optional thumbnail concise enough to read quickly.
  • Implement pointer handoff so the card remains visible while pointer moves from trigger to content.
  • Support keyboard focus opening and Escape dismissal, or provide a separate explicit keyboard route to the same preview.
  • Close or reanchor when the trigger scrolls, is removed, changes object identity, or moves near viewport edges.
  • Avoid hidden-only content: expose profile pages, details links, or inline equivalents for touch and assistive-technology users.
  • Test dense list scanning, repeated rows, stale data, slow network preview loading, zoom, scroll containers, collision, pointer jitter, keyboard focus, and screen readers.

Common Generated-UI Mistakes

  • Using a hover card as the only place for required instructions or validation help.
  • Putting forms, filters, destructive commands, or multi-step workflows inside the card.
  • Opening on hover only with no keyboard or explicit route to the same preview.
  • Closing as soon as the pointer leaves the trigger, before users can inspect the card.
  • Showing stale preview data for the previously hovered row.
  • Using long open delays that make the preview feel unreliable.
  • Letting the card cover the trigger or nearby content without Escape dismissal.
  • Using hover cards on touch-first interfaces where hover cannot be invoked reliably.

Critique Questions

  • What exact object does this hover card preview?
  • Is the preview useful before navigation, or would a normal link, tooltip, popover, drawer, or page be clearer?
  • Can users reach equivalent information without pointer hover?
  • Can users move from trigger to card, dismiss with Escape, and keep focus on the trigger?
  • What happens when the row recycles, the object changes, the trigger scrolls, or the preview fetch is slow?
  • Is any required instruction, destructive action, or multi-step workflow hidden in this transient preview?
Accessibility
  • Do not rely on hover card content as the only source of required information.
  • Make the trigger keyboard focusable and expose a usable name for the referenced object.
  • Support Escape dismissal when the card appears on focus or hover.
  • Keep pointer-triggered content hoverable so users can move into it without disappearance.
  • Keep hover-card content persistent while the trigger or card is hovered or focused.
  • Provide an explicit route to the full object or equivalent preview for touch and assistive-technology users.
  • Avoid focusable controls inside a hover card unless the surface is implemented as a stable popover with a clear focus model.
  • Do not rely on placement, color, image, or avatar alone to identify the object being previewed.
Keyboard Behavior
  • Tab moves focus to the trigger and may open the hover card for the focused object.
  • Escape dismisses the hover card and leaves focus on the trigger.
  • Tab away closes the hover card after focus leaves the trigger or explicit card route.
  • Enter or Space follows or activates the trigger's primary route, not the preview itself.
  • If the implementation supports a hotkey to enter card content, focus moves to the first intentional control and the surface should behave like a popover.
  • Arrow keys belong to the underlying list, grid, or trigger component, not to generic hover-card navigation.
Variants
  • Profile hover card
  • File hover card
  • Issue hover card
  • Mention hover card
  • Chart mark hover card
  • Reference preview card
  • Activity hover card
  • Object metadata hover card

Verification

Last verified: