Popover

Introduction

Popover is a composite pattern containing an element (typically a button) that hosts a non-modal overlay element. The overlay discloses contextually relevant secondary content and/or actions.

Popover forms the basis of the following composite patterns:

• Comboxbox
• Fake Menu Button
• Infotip Button
• Listbox Button
• Menu Button
• Tooltip
• Tourtip

The pattern discussed here in this document is a more generic use-case, where the popover may contain any kind of content.

Best Practices

The overlay can hold any kind of content, but for an overlay that demands user acknowledgement or input, or with additional rich interactions, consider using a dialog instead.

The overlay expands or collapses via any combination of the following events:

• Click event of host
• Hover event of host (discouraged)
• Focus event of host (discouraged)
• System event at page load or after some arbitrary time

A link must not be the host of a click-activated popover. Clicking the host should always navigate to the URL in this case.

Overlay must be non-modal (i.e. must not trap keyboard focus or mask page background). For modal behaviour please consider the dialog pattern instead.

Overlay must be placed directly after the host in DOM. This ensures natural tab order and reading order without JavaScript.

If system-activated (e.g. a Tourtip ), overlay must remain onscreen until explicitly dismissed by the user.

If focus-activated, overlay shouldnot contain long blocks of interactive elements. This measure prevents keyboard users from having to tab through secondary or tertiary content inside of the overlay.

Interaction Design

This section provides interaction guidelines for keyboard, screen reader, and pointing devices.

Keyboard

Tab order must flow directly from host into first focusable element inside overlay. If the overlay has no focusable element, tab order flows to next page control instead.

If not system-activated, host must be keyboard focus-able.

If click-activated, popover must expand overlay when host receives keyboard click.

If focus-activated (discouraged), popover must expand when host receives keyboard focus.

If focus-activated (discouraged), popover must collapse when flyout loses keyboard focus.

Screen Reader

Reading order must flow directly from host into overlay.

Overlay must not be conveyed as a dialog.

If system-activated and high-priority, screen reader must announce presence and/or content overlay.

Mouse

If hover-activated (discouraged), popover must expand when host receives mouse hover.

If hover-activated (discouraged), popover must collapse when mouse leaves flyout.

If click-activated, popover must expand when host receives mouse click.

If system-activated, popover must collapse when clicking close button.

Touch

Hover behaviour can be problematic or impossible for touch. You may wish to consider using the Infotip pattern instead.

If click-activated, popover must expand when host receives tap.

if system-activated, popover must close when tapping close button.

ARIA Reference

FAQ

Didn’t this pattern used to be called Flyout?

Yes it did! In most practical senses, the term flyout is synonomous with popover; they are both used to describe transient (i.e. non-modal) overlays of content.