Keep content and actions reachable when they exceed the available space.
Overflow occurs when text, actions, or structured content need more room than their container provides. Choose a response based on what people need to read or operate. Hiding the excess can remove the very information needed to complete the task.
| Content | Starting point |
|---|---|
| Paragraphs and labels | Wrap and allow the container to grow |
| Secondary commands | Move deliberately into a labeled Menu |
| Long identifiers | Preserve access to the full value and copying |
| Wide content whose relationships need two dimensions | A deliberate scroll region with clear context |
| Supporting detail | A DisclosureGroup when the detail can remain optional |
Use Text with a supported wrapping option, page-owned layout classes for containment, and Menu or DisclosureGroup for their specific interactions. Do not assume that BarLayout or ControlGroup automatically turns clipped content into an overflow menu.
Figure in preparation
Overflow content: interaction sequence
Different content needs different responses to limited space.
For project actions, keep the main save action visible and move less frequent commands into “More actions” only when needed. Use the same command labels and outcomes in both locations. If resizing removes the focused control, choose a predictable visible focus target.
Handle long content, enlarged text, narrow viewports, and loading or error messages that expand a region. A layout that fits only its initial data is incomplete. If a menu action fails, surface the error near the task after the menu closes rather than hiding it inside the closed menu.
Make scrolling apparent through visible content boundaries or a clear label when necessary. Preserve native scrolling and avoid competing vertical scroll areas for ordinary reading. When using AdaptiveAppLayout, account for its existing content scroller before adding another.
Truncation should be a deliberate secondary treatment. If the full value matters, provide an accessible way to read or copy it. A hover-only tooltip is not a sufficient path for keyboard and touch users.
Name a command menu by its scope, such as “More project actions,” when several exist. Avoid “More” for both navigation and unrelated editing actions in the same area.
Check keyboard access to genuinely scrollable regions and use an accessible name when an additional focusable region is necessary. Do not add tab stops to every container. Test that focused controls, menu panels, and text remain inside the usable viewport at narrow widths and increased text sizes.
Preserve meaningful DOM order during reflow. If a label wraps, keep its control association and focus indicator intact. Avoid solving overflow by shrinking text or targets below the product's accessibility requirements.
See Text, Menu, DisclosureGroup, and AdaptiveAppLayout. Read Fluid styles for token-based responsive decisions.