Carousel

Problem Context

• Several peer items compete for one constrained display area such as a product tour, media gallery, promotion slot, onboarding preview, or small content rail.
• Only one slide or a small subset should be visible at a time, and users do not need to compare all slides simultaneously.
• The team can keep controls, labels, current position, motion state, and focus behavior synchronized.
• No required decision, warning, or primary action depends on users seeing a hidden slide at the right time.

Selection Rules

• Choose carousel when a small set of peer slides must share a constrained visual slot and users can move through them with explicit controls.
• Use static content, page sections, list view, card grid, or collection when every item matters or comparison is important.
• Use tabs when the labels are meaningful section names and users are switching content panels rather than moving through slides.
• Use pagination when users move through a large ordered set with page numbers, ranges, totals, and result persistence.
• Use recommendations or recently viewed when the underlying job is ranked suggestion or recency history; carousel may only be the rail presentation.
• Avoid auto-advance by default, especially for text-heavy, task-critical, mobile, or assistive-technology contexts.
• If auto-advance exists, put the stop or pause control before slide-changing controls in tab order and stop rotation on focus and hover.
• Do not hide required fields, critical warnings, primary navigation, or irreversible actions on non-visible slides.
• Use named slide picker controls, thumbnails, or tabs when users need direct access to known slides; dots without names are insufficient.
• Keep swipe gestures as an enhancement, not the only control path.

Required States

• Initial slide state with carousel label, slide identity, current position, and previous or next controls.
• Manual next and previous state with focus preserved on the activated control.
• Direct slide picker state with current slide indicated and picker names exposed.
• Paused rotation state when auto-advance is stopped by user command, focus, or hover.
• Playing rotation state only when motion is explicit and controllable.
• Last and first slide boundary state for finite carousels or clear wrap behavior for looping carousels.
• Loading media or failed slide state with stable controls and no skipped focus.
• Reduced motion state where rotation and animated transitions are disabled or minimized.
• Small viewport state with reachable controls and readable slide content.

Interaction Contract

• Previous and next controls change the current slide by one step or follow a clearly indicated wrap rule.
• Slide picker controls move directly to a named slide and expose which slide is current.
• If rotation starts automatically, focus entering the carousel stops it and the stop or pause control remains available.
• Hovering or interacting with slide content stops rotation until the user explicitly resumes or leaves according to the documented behavior.
• Changing slides does not move keyboard focus into hidden content or remove focus from the activated control.
• Only the current visible slide or visible subset is exposed as current content; hidden slides are not reachable as if they were visible.
• Slide content links and buttons remain ordinary interactive controls and do not conflict with carousel navigation.

Implementation Checklist

• Decide whether carousel is justified by space constraints or whether a static section, list, grid, tabs, or pagination would be clearer.
• Define slide IDs, names, order, count, current position, and wrap behavior before rendering controls.
• Provide Previous, Next, direct slide picker controls, and a pause or play control when rotation exists.
• Label every control by action and slide target, such as Next slide, Previous slide, Stop slide rotation, or Show Backup checklist slide.
• Stop rotation on focus and hover, respect reduced motion, and avoid starting rotation for text-heavy or task-critical content.
• Preserve keyboard focus after slide changes and prevent hidden slide controls from staying in tab order.
• Announce slide changes through a polite status only for user-initiated changes, not for constant automatic motion.
• Test keyboard, screen reader, pointer hover, swipe enhancement, reduced motion, first and last slide boundaries, mobile layout, and content links.

Common Generated-UI Mistakes

• Auto-advancing slides without a pause or stop control.
• Using unlabeled dots with no current-slide name or state.
• Hiding critical content or required tasks on later slides.
• Using a carousel because multiple stakeholders want homepage priority instead of designing a clear information hierarchy.
• Treating carousel as the whole pattern when the rail actually contains recommendations, recently viewed items, related links, or cards that need their own rules.
• Making swipe the only way to move slides.
• Leaving controls inside hidden slides in the keyboard tab order.
• Letting slide changes steal focus or reset partially read media.

Critique Questions

• Why must these items share one slot instead of being static, listed, or grouped?
• Can users pause motion before the carousel changes content?
• Can users identify the current slide, total count, and target of each slide picker?
• What happens when focus or pointer enters the carousel?
• Is any required information, warning, form field, or primary task hidden on another slide?
• Would tabs, pagination, recommendations, recently viewed, a grid, or a list better match the user's job?