presentation form · Structural containers and states
Avatar Group
A compact row or stack of user avatars that represents several people while limiting visible items and summarizing the remainder with a surplus count.
Decisive boundary
Use an Avatar Group for a compact people summary; use a list when every person and label must be visible or independently actionable.
Definition and intent
What is a Avatar Group UI pattern?
Use the behavior, not the silhouette
A compact row or stack of user avatars that represents several people while limiting visible items and summarizing the remainder with a surplus count. 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.
Show that several people are associated with an item without spending the space required by a full member list. 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 Avatar Group, the boundary is: Use an Avatar Group for a compact people summary; use a list when every person and label must be visible or independently actionable.
Do not implement it as A single Avatar for one identity and a people list when names, roles, or actions must remain visible. If those requirements describe the real task better, use the related pattern page or the full Structural containers and states 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
Show that several people are associated with an item without spending the space required by a full member list.
Define opening and closing
Usually always visible as a summary; optional interaction may open the full member list. Not applicable unless a separate member-list surface is opened.
Specify access behavior
Decorative avatars stay out of the focus order; interactive people or the surplus control need accessible names. Any avatar link or surplus button follows normal keyboard order and exposes the same information as pointer interaction.
Reject the near miss
A single Avatar for one identity and a people list when names, roles, or actions must remain visible.
Behavior contract
What must survive the build
- trigger
- Usually always visible as a summary; optional interaction may open the full member list.
- dismissal
- Not applicable unless a separate member-list surface is opened.
- modality
- Non-modal inline summary.
- focus
- Decorative avatars stay out of the focus order; interactive people or the surplus control need accessible names.
- keyboard
- Any avatar link or surplus button follows normal keyboard order and exposes the same information as pointer interaction.
- interactive
- May link to profiles or open a complete member list, but the group itself can remain informational.
- persistence
- Reflects the current membership or participants associated with the item.
- placement
- Inline near ownership, collaborators, participants, or assigned users.
- mobile
- Limit visible avatars and keep the surplus control readable without shrinking tap targets.
Failure modes
Common wrong builds
- Hiding every person name from assistive technology.
- Displaying an inaccurate surplus count.
- Making tiny overlapping avatars separate touch targets.
Observable checks
Verify the result
- Every meaningful avatar has an accessible name.
- The surplus count matches the hidden people.
- The complete member list remains reachable when required.
- Overlap does not obscure identity beyond recognition.
- Mobile sizing preserves readable counts and usable controls.
Coding-agent handoff
Implementation brief template
Pattern: Avatar Group Purpose: Show that several people are associated with an item without spending the space required by a full member list. Trigger: Usually always visible as a summary; optional interaction may open the full member list. Dismissal behavior: Not applicable unless a separate member-list surface is opened. Modality: Non-modal inline summary. Focus behavior: Decorative avatars stay out of the focus order; interactive people or the surplus control need accessible names. Keyboard behavior: Any avatar link or surplus button follows normal keyboard order and exposes the same information as pointer interaction. Interactive content: May link to profiles or open a complete member list, but the group itself can remain informational. Placement: Inline near ownership, collaborators, participants, or assigned users. Mobile behavior: Limit visible avatars and keep the surplus control readable without shrinking tap targets. Do not implement as: A single Avatar for one identity and a people list when names, roles, or actions must remain visible. Acceptance checks: - Every meaningful avatar has an accessible name. - The surplus count matches the hidden people. - The complete member list remains reachable when required. - Overlap does not obscure identity beyond recognition. - Mobile sizing preserves readable counts and usable controls.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Avatar Group UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Avatar Group in web UI?
A compact row or stack of user avatars that represents several people while limiting visible items and summarizing the remainder with a surplus count. In this reference set it is a presentation form that describes placement or motion without deciding every semantic behavior.
When should I use a Avatar Group?
Show that several people are associated with an item without spending the space required by a full member list. The decisive boundary to confirm is this: Use an Avatar Group for a compact people summary; use a list when every person and label must be visible or independently actionable.
What keyboard and focus behavior does a Avatar Group need?
Any avatar link or surplus button follows normal keyboard order and exposes the same information as pointer interaction. Decorative avatars stay out of the focus order; interactive people or the surplus control need accessible names. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Avatar Group behave on mobile?
Limit visible avatars and keep the surplus control readable without shrinking tap targets. Its modality is a separate requirement: Non-modal inline summary.
How do I verify a Avatar Group implementation?
Start with observable checks: Every meaningful avatar has an accessible name. The surplus count matches the hidden people. The complete member list remains reachable when required. Then verify the remaining checks and compare the result with the linked source guidance.