composite pattern · Dialog and side surfaces
Carousel
A rotating strip of slides that users can navigate with arrow buttons, dot indicators, or swipe gestures, with optional autoplay and pause.
Decisive boundary
A carousel presents a sequence of content items. Do not use it where every slide must be visible at once, or where autoplay would distract or disorient.
Definition and intent
What is a Carousel UI pattern?
Use the behavior, not the silhouette
A rotating strip of slides that users can navigate with arrow buttons, dot indicators, or swipe gestures, with optional autoplay and pause. The term is used here as a composite pattern made from multiple controls or regions that must work together. That distinction prevents a visual resemblance from silently deciding focus, keyboard, modality, or dismissal behavior.
Present a sequence of content items or images in a compact region without stacking them vertically. 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 Carousel, the boundary is: A carousel presents a sequence of content items. Do not use it where every slide must be visible at once, or where autoplay would distract or disorient.
Do not implement it as Accordion when content is textual and expandable, and Tabs when users need to switch predictably between labeled views. If those requirements describe the real task better, use the related pattern page or the full Dialog and side surfaces 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
Present a sequence of content items or images in a compact region without stacking them vertically.
Define opening and closing
Autoplay on load or manual trigger via arrow buttons, dot indicators, or swipe. Not dismissed; arrows and dots navigate slides without closing the carousel.
Specify access behavior
Arrow and dot controls follow normal tab order; some carousels trap focus when in fullscreen or modal view. Arrow keys navigate slides when focus is inside the carousel; Tab reaches next/prev and dot controls.
Reject the near miss
Accordion when content is textual and expandable, and Tabs when users need to switch predictably between labeled views.
Behavior contract
What must survive the build
- trigger
- Autoplay on load or manual trigger via arrow buttons, dot indicators, or swipe.
- dismissal
- Not dismissed; arrows and dots navigate slides without closing the carousel.
- modality
- Non-modal inline content region.
- focus
- Arrow and dot controls follow normal tab order; some carousels trap focus when in fullscreen or modal view.
- keyboard
- Arrow keys navigate slides when focus is inside the carousel; Tab reaches next/prev and dot controls.
- interactive
- Each slide may contain links, buttons, or images; autoplay must pause on hover or focus.
- persistence
- Slides continue until navigated or autoplay stops; no persistent state between sessions.
- placement
- Inline content region, often full-width within a section.
- mobile
- Swipe gestures supplement arrow buttons; autoplay pauses on interaction; dots must be tappable.
Failure modes
Common wrong builds
- Autoplaying without a pause control.
- Hiding navigation controls.
- Making slides rely entirely on animation timing.
- Omitting touch support for mobile.
- Skipping aria-live or roledescription for the carousel region.
Observable checks
Verify the result
- Arrow buttons or dot indicators are present.
- Autoplay pauses on hover or focus.
- Swipe is supported on mobile.
- Each slide announces its position.
- Keyboard navigation reaches all controls.
Coding-agent handoff
Implementation brief template
Pattern: Carousel Purpose: Present a sequence of content items or images in a compact region without stacking them vertically. Trigger: Autoplay on load or manual trigger via arrow buttons, dot indicators, or swipe. Dismissal behavior: Not dismissed; arrows and dots navigate slides without closing the carousel. Modality: Non-modal inline content region. Focus behavior: Arrow and dot controls follow normal tab order; some carousels trap focus when in fullscreen or modal view. Keyboard behavior: Arrow keys navigate slides when focus is inside the carousel; Tab reaches next/prev and dot controls. Interactive content: Each slide may contain links, buttons, or images; autoplay must pause on hover or focus. Placement: Inline content region, often full-width within a section. Mobile behavior: Swipe gestures supplement arrow buttons; autoplay pauses on interaction; dots must be tappable. Do not implement as: Accordion when content is textual and expandable, and Tabs when users need to switch predictably between labeled views. Acceptance checks: - Arrow buttons or dot indicators are present. - Autoplay pauses on hover or focus. - Swipe is supported on mobile. - Each slide announces its position. - Keyboard navigation reaches all controls.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Carousel UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Carousel in web UI?
A rotating strip of slides that users can navigate with arrow buttons, dot indicators, or swipe gestures, with optional autoplay and pause. In this reference set it is a composite pattern made from multiple controls or regions that must work together.
When should I use a Carousel?
Present a sequence of content items or images in a compact region without stacking them vertically. The decisive boundary to confirm is this: A carousel presents a sequence of content items. Do not use it where every slide must be visible at once, or where autoplay would distract or disorient.
What keyboard and focus behavior does a Carousel need?
Arrow keys navigate slides when focus is inside the carousel; Tab reaches next/prev and dot controls. Arrow and dot controls follow normal tab order; some carousels trap focus when in fullscreen or modal view. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Carousel behave on mobile?
Swipe gestures supplement arrow buttons; autoplay pauses on interaction; dots must be tappable. Its modality is a separate requirement: Non-modal inline content region.
How do I verify a Carousel implementation?
Start with observable checks: Arrow buttons or dot indicators are present. Autoplay pauses on hover or focus. Swipe is supported on mobile. Then verify the remaining checks and compare the result with the linked source guidance.