Layout switches must keep elements recognisably the same

What it is

A wide-to-narrow layout switch changes position, order, and density. It must not change object identity. The search field is still that search field, the primary action is still that action, the nav items are still that set of destinations — name, icon, accessible name, and primary behaviour remain recognisable across the cut. Only then do the two arrangements read as one interface in two poses, not as two products. If the narrow side replaces search with an icon that does not share the name, swaps primary nav for a different set of labels, or hides the main button in a menu with no counterpart on the wide side, identity breaks.

This is whether something is still the same thing after the switch — not which width the breakpoint is pinned to, and not whether landscape and split-screen share rules.

Why it happens

People track objects by stable perceptual cues: shape, label, relative role — not absolute coordinates. Reflow already breaks coordinates. If labels, icons, or control types change in the same moment, tracking fails; users assume the function was removed and start searching again. A common "hamburgerisation" is not two poses of one object unless the menu items are the same labels and the same routes as the wide nav. A solid primary button that becomes a glyph-only FAB with a different accessible name is a new control to voice control and to a screen-reader rotor.

Continuity is identity-level, not pixel-level: stacking into a column or moving into an overflow menu is allowed, but the items in that menu are still those items, and the menu's entry must be readable as "those nav items live here". Position may change; role may not be quietly renamed — wide "Filter" cannot become narrow "More" while still opening the same panel.

Where it stops holding

Deliberate mode changes (reading mode dropping edit tools, a checkout step showing only this step's fields) reduce the object set because the task stage changed, not because the viewport narrowed; objects that disappear must be ones that should not exist at that stage anyway. Marketing landing pages that tell different stories at different widths rank narrative above identity; do not grade them as tools. At extreme narrowness an icon may remain graphic-only with the name carried by aria-label — visual identity weakens, semantic identity can still continue, provided the name is actually the same. A desktop installable and a mobile installable are not two sides of one layout switch; do not pretend they are breakpoint sides.

Applying it

• List objects that must be recognised across widths (primary nav, search, primary action, user menu, key filters). On each side of every breakpoint, check that visible label or icon, accessible name, and target URL or action match.
• Items collapsed into overflow or a bottom bar keep the same names and icons as on the wide side; the entry must read as "those items are in here".
• Do not rewrite information architecture at a cut: do not substitute a different set of nav labels, and do not replace the primary action with a new control that has no matching name.
• How to check: place wide and narrow screenshots side by side, paint out coordinates, and ask someone who did not design it to pair "is this the same thing". Every unpaired couple is a broken identity. Then compare screen-reader control lists: the name sets on both sides should match.

Related

• Same group: R3.11.1 Breakpoints belong where content becomes hard to read, not at device widths · R3.11.3 Landscape and split-screen are different width values of the same rules
• Nearby: R3.03 Responsive Implementation · K1.02 Screen Size and Density
• Search terms: layout identity continuity · object constancy · responsive identity