Accessibility · Inclusive Design

Reflow Under Magnification: What a Layout Must Give Up at 320 CSS Pixels

How text scaling and page zoom change the effective viewport, which layout techniques fail first under magnification, and the constraints that keep content usable when the viewport shrinks to a narrow column.

Magnification is a layout event disguised as a display setting. When a user zooms a page to 400 percent, the browser does not enlarge the layout and then shrink it to fit; it reduces the number of CSS pixels available to the viewport by a factor of four and lays the page out in the space that remains. A viewport that was 1280 CSS pixels wide becomes 320. Every media query, every minimum width, every fixed column, and every absolutely positioned element now operates in a space a quarter of the size it was designed for.

That is the whole mechanism, and it explains why the failure mode of magnification is not “text is too big” but “content is clipped, overlapped, or pushed off-screen”. The text is the correct size. The container is the wrong size, because it was sized in absolute units or positioned in a way that assumed a wider viewport.

Two axes: zoom and text scaling

There are two independent magnification mechanisms, and they fail differently.

Page zoom scales everything: CSS pixels, images, borders, and the viewport’s CSS pixel count. A layout that uses relative units throughout reflows correctly under zoom, because reflow is what happens when a responsive layout meets a narrow viewport. A layout with a fixed-width container does not: at 400 percent, a 960-pixel container is 3840 CSS pixels wide in a 320-pixel viewport, and the page scrolls horizontally.

Text-only scaling enlarges the font size without changing the viewport. This is the harder case, because the viewport stays wide while the content inside it grows. A container with a fixed height sized for two lines of 16-pixel text now holds two lines of 32-pixel text and clips the second, and a container with a fixed height and overflow: hidden silently deletes content. The constraint that addresses this is text spacing: line height, paragraph spacing, letter spacing, and word spacing must be adjustable to stated multiples without loss of content, which means no container may have a height derived from an assumed line count.

/* Fails under text scaling: the height is tied to a line count. */
.badge {
  block-size: 24px;
  overflow: hidden;
  white-space: nowrap;
}

/* Holds: the box grows with its content, and wrapping is allowed. */
.badge {
  min-block-size: 24px;
  padding-block: var(--space-1);
  overflow-wrap: anywhere;
}

The distinction between block-size and min-block-size is the whole constraint in one property. A minimum is a floor that content can exceed; a fixed size is a ceiling that content cannot.

The 320-pixel budget

The reflow criterion is usually expressed as: content must be presentable without two-dimensional scrolling at a width equivalent to 320 CSS pixels, which corresponds to a 1280-pixel viewport at 400 percent zoom. The number is a budget, and treating it as one is more useful than treating it as a pass or fail.

At 320 CSS pixels, the following are the scarce resources.

Horizontal space per line is roughly 320 pixels minus any padding, minus any scrollbar. At a 16-pixel body size, that is around 30 to 40 characters per line. That is narrow but readable; below roughly 25 characters, reading becomes a word-by-word exercise because the eye cannot fixate on a phrase.

Vertical space is not scarce, which is the point. Reflow converts horizontal pressure into vertical length. Content that was in three columns becomes three stacked sections, and the page gets longer. This is the trade the criterion demands: length for width, because vertical scrolling is a normal interaction and horizontal scrolling of a page is not.

Fixed-position elements become expensive. A sticky header that occupies 80 pixels of a 640-pixel-tall viewport is 12 percent; at 400 percent zoom the viewport height in CSS pixels is also divided by four, so the header occupies a much larger fraction of what remains, and a sticky footer that was 60 pixels can consume most of a short viewport. The constraint is that sticky elements must be allowed to scroll away when the viewport is short, which is a media query on height rather than on width.

/* A sticky header that yields when vertical room is scarce. */
.site-header {
  position: sticky;
  inset-block-start: 0;
}

@media (max-height: 480px) {
  .site-header {
    position: static;
  }
}

Side-by-side layouts have to collapse, and the collapse point is determined by the content, not by device categories. A two-column layout with a 240-pixel sidebar needs at least 240 plus a readable main column, which at 320 pixels total is impossible; the columns must stack. The container query form of this constraint is better than the media query form, because the component then responds to the space it actually has rather than to the viewport, and a card in a narrow column of a wide page gets the same treatment as a card on a narrow screen.

Which layout techniques fail, and why

Fixed widths. A width: 960px container cannot reflow. The replacement is max-width, which behaves identically at wide viewports and shrinks at narrow ones. This substitution alone fixes a large share of reflow failures.

Percentage widths with fixed padding. A width: 50% element with padding: 0 24px and default box-sizing: content-box is 50 percent plus 48 pixels wide, which overflows its parent at narrow widths. The border-box model makes the declared width inclusive of padding, and applying it globally is the usual remedy. This is a sizing model difference, not a bug in either model.

Fixed-height media. An image with height: 400px and width: auto maintains its aspect ratio only if the other axis is free; with both axes constrained it distorts or overflows. The constraint is to express one dimension and let the other follow, or to use aspect-ratio.

Absolutely positioned content. An element positioned with left: 500px is positioned relative to its containing block, not to the viewport, and it does not move when the viewport narrows. Any layout that uses absolute positioning for content (rather than for decoration) has to be re-expressed in flow.

Data tables. A table with many columns cannot reflow into a narrow viewport without either horizontal scrolling or a change of presentation. The criterion permits two-dimensional scrolling for content that requires it, such as a data table or a map, so a wide table is not automatically a failure. The constraint is that the table must be the only thing scrolling horizontally, not the page around it, which means the table needs its own scroll container with a keyboard-reachable scrollbar.

Text in images. A banner image containing a headline does not reflow at all; it scales with the zoom and becomes either unreadably small relative to the viewport or clipped. The constraint is that text is never part of a raster image except where the image is a logo or the text is incidental to a photograph.

Reflow is not the same as responsive

A responsive design that has breakpoints at common device widths may still fail the reflow criterion, because the breakpoints are tuned to devices and the criterion is about a continuous range. A layout that is comfortable at 375 pixels and at 768 pixels but has a fixed sidebar between those widths will break at 500 pixels under text scaling, which the device breakpoints never exercise.

The practical test is to set the viewport to 320 CSS pixels and walk the content at 400 percent zoom, checking for horizontal page scroll, clipped text, overlapping elements, and content that disappears behind a fixed element. The second test is to apply the text-spacing overrides (line height 1.5, paragraph spacing twice the font size, letter spacing 0.12em, word spacing 0.16em) at the default zoom, which exercises the fixed-height failure mode that zoom does not.

Both tests are mechanical, which is what makes the constraint enforceable. A design system can carry the reflow requirement as a property of its layout primitives: a container that is always max-width and never width, a grid that collapses on container width rather than viewport width, and a sticky element that yields on short viewports. That is the same argument for moving constraints from review into components, applied to a constraint that is unusually easy to regress, because a single fixed height anywhere in a template reintroduces the failure.

Where the constraint collides with others

Reflow is a good example of a constraint that cannot be satisfied in isolation, because it trades against three others.

It trades against information density. A dense dashboard that shows twelve metrics at once cannot show twelve at 320 pixels without either stacking them (which destroys comparison) or shrinking them (which destroys legibility). The resolution is usually to change the presentation at narrow widths rather than to preserve the layout: a table becomes a list of records, and comparison moves to a view that the user opts into.

It trades against target size. A toolbar of eight 24-pixel controls needs 192 pixels plus gaps, which fits in 320; a toolbar of twenty does not, and wrapping it consumes vertical space that the reflow already needed. The Fitts’s law floor on target size is not negotiable at narrow widths, so the toolbar has to change shape rather than shrink.

It trades against content order. When columns stack, the stacking order is the document order, and the document order was authored for the wide layout. A sidebar that reads well to the right of the main content may read poorly above it, which is the linearization problem in its responsive form. The fix is to author the document in the order that works when stacked, and use layout to place it when there is room.

References

  1. Web Content Accessibility Guidelines (WCAG) 2.2 — Reflow — W3C
  2. CSS Overflow Module Level 3 — W3C
  3. CSS Values and Units Module Level 4 — W3C
  4. CSS Box Sizing Module Level 3 — W3C