generic behavior · Progressive disclosure
Collapsible
A generic behavior in which a region can collapse or expand; it does not by itself define the surrounding semantic structure.
Decisive boundary
Choose a specific semantic pattern when the relationship is actually a Disclosure or Accordion.
Definition and intent
What is a Collapsible UI pattern?
Use the behavior, not the silhouette
A generic behavior in which a region can collapse or expand; it does not by itself define the surrounding semantic structure. The term is used here as a generic behavior label that still needs a more specific semantic structure around it. That distinction prevents a visual resemblance from silently deciding focus, keyboard, modality, or dismissal behavior.
Add controlled visibility to a region whose semantics come from another structure. 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 Collapsible, the boundary is: Choose a specific semantic pattern when the relationship is actually a Disclosure or Accordion.
Do not implement it as Using a generic Collapsible label when a known Disclosure or Accordion contract applies. If those requirements describe the real task better, use the related pattern page or the full Progressive disclosure 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
Add controlled visibility to a region whose semantics come from another structure.
Define opening and closing
A clearly labeled control or application state change. The same or equivalent control restores the collapsed state.
Specify access behavior
Focus must not become hidden when the region collapses. The control is keyboard operable and communicates state.
Reject the near miss
Using a generic Collapsible label when a known Disclosure or Accordion contract applies.
Behavior contract
What must survive the build
- trigger
- A clearly labeled control or application state change.
- dismissal
- The same or equivalent control restores the collapsed state.
- modality
- Non-modal layout behavior.
- focus
- Focus must not become hidden when the region collapses.
- keyboard
- The control is keyboard operable and communicates state.
- interactive
- The region may contain controls, but hidden focused content must be handled safely.
- persistence
- State may persist as a layout preference when explicitly designed.
- placement
- Inline or structural region such as a panel, rail, or code block.
- mobile
- Ensure the collapsed control remains discoverable and does not hide required actions.
Failure modes
Common wrong builds
- Hiding the currently focused element.
- Removing the only way to expand again.
- Treating collapse animation as semantics.
Observable checks
Verify the result
- A visible control restores the region.
- State is exposed.
- Focus never remains inside hidden content.
- Layout remains stable enough to follow.
- A more specific semantic pattern was considered.
Coding-agent handoff
Implementation brief template
Pattern: Collapsible Purpose: Add controlled visibility to a region whose semantics come from another structure. Trigger: A clearly labeled control or application state change. Dismissal behavior: The same or equivalent control restores the collapsed state. Modality: Non-modal layout behavior. Focus behavior: Focus must not become hidden when the region collapses. Keyboard behavior: The control is keyboard operable and communicates state. Interactive content: The region may contain controls, but hidden focused content must be handled safely. Placement: Inline or structural region such as a panel, rail, or code block. Mobile behavior: Ensure the collapsed control remains discoverable and does not hide required actions. Do not implement as: Using a generic Collapsible label when a known Disclosure or Accordion contract applies. Acceptance checks: - A visible control restores the region. - State is exposed. - Focus never remains inside hidden content. - Layout remains stable enough to follow. - A more specific semantic pattern was considered.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Collapsible UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Collapsible in web UI?
A generic behavior in which a region can collapse or expand; it does not by itself define the surrounding semantic structure. In this reference set it is a generic behavior label that still needs a more specific semantic structure around it.
When should I use a Collapsible?
Add controlled visibility to a region whose semantics come from another structure. The decisive boundary to confirm is this: Choose a specific semantic pattern when the relationship is actually a Disclosure or Accordion.
What keyboard and focus behavior does a Collapsible need?
The control is keyboard operable and communicates state. Focus must not become hidden when the region collapses. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Collapsible behave on mobile?
Ensure the collapsed control remains discoverable and does not hide required actions. Its modality is a separate requirement: Non-modal layout behavior.
How do I verify a Collapsible implementation?
Start with observable checks: A visible control restores the region. State is exposed. Focus never remains inside hidden content. Then verify the remaining checks and compare the result with the linked source guidance.