Resize must not force two-dimensional scrolling
Aliases: bidirectional scrolling · horizontal overflow · 2D scrolling
What it is
After text is enlarged, reading a stretch of prose should scroll on one axis — usually vertical. Needing to pan left-right and up-down to finish a line is two-dimensional scrolling. The failure is not “a scrollbar appeared.” It is that the reading window became a keyhole that must be translated across a plane. Low-vision viewports are already small; a second axis makes assembling a sentence in working memory expensive.
Why it happens
The viewport is a finite rectangle. If layout keeps its old minimum width after type grows, document width exceeds the viewport and vertical scroll is joined by page-level horizontal scroll. People read left to right then return to the next line’s start; once the horizontal offset does not reset, finding that start is a hunt. That is not the same as a widget that pans in two dimensions: tables, code blocks, and maps may scroll inside their own box so long as they do not stretch body.
One hero, one nowrap table, one grid with min-width: 1200px is enough to turn the whole page into a 2D canvas. The words may still be present and unclipped, yet the way of getting them is broken — so “no loss of content” can pass while this criterion fails. Reflow into a single column at higher magnification is a stricter, separate requirement. This leaf first blocks page-level dual-axis scrolling at the checkpoint.
Studying it
At 200% enlargement, compare scrollWidth with clientWidth, then actually finish a paragraph and note whether sideways pan is required. Log widget-level versus document-level horizontal scroll separately.
Independent variables: enlargement factor, page minimum width, presence of a non-shrinking wide widget. Dependent variables: whether the document scrolls horizontally, pan counts to finish a paragraph, whether line starts are lost.
Keyboard users lack a trackpad’s diagonal drag, so dual-axis cost shows sooner. Do not “fix” a failure by widening the window; the test viewport should be near the product’s stated minimum.
Where it stops holding
Data tables, scores, maps, and drawing canvases are explicitly two-dimensional media and may pan inside their own box if surrounding prose stays one-axis. Mobile is already narrow; enlarge overflows the page faster — “phones can swipe sideways” is not a pass. Users who shrink the window past the stated viewport are outside the claim. Browser chrome zoom and text-only zoom expose different horizontal overflows and should be tested apart; the criterion is the same: do not read prose on two axes.
Applying it
- Size columns with
%,max-width: 100%, or wrapping tracks. Do not lock the page to a largemin-width. - Wrap genuinely wide widgets (tables, code, canvases) in their own scroll box. Do not let them stretch
body. - Let long URLs, nowrap code, and preformatted whitespace wrap or scroll only inside the widget.
- Verify: at the stated minimum viewport, set text to 200%, read a paragraph start to end without panning sideways. A page-level horizontal scrollbar fails. Horizontal scroll only inside a table is noted as a widget, not a page fail.