Zoom and font-size settings must both be tested

What it is

Whether a responsive implementation holds has to pass on browser zoom and user font size, not on one path. Zoom enlarges the page as a picture, including px-measured slots, images, and viewport breakpoints. Font size (OS type, browser default, root rem) enlarges glyphs while slots and images often stay on the old pixels. Wrapping that looks fine on one path can overflow, occlude, or crush controls on the other.

This is an acceptance matrix. Both magnifications are switches real people use. A row of “200% zoom” screenshots has measured only one of them.

Why it happens

Zoom changes the relation between CSS pixels and device pixels; the width numbers layout uses move with it, px breakpoints fire earlier, and images grow. Font-size settings change computed text: control heights locked in px, icons that do not follow type, slots metered on the viewport instead of on type, stay put while glyphs swell inside the box. The same word “magnify” then means two stresses: one fires more breakpoints, one crowds type in a fixed slot.

Testing only zoom misses truncation and overlap from swelling type in an unmoved slot. Testing only font size misses what happens when zoom treats the page as a large picture and breakpoints and hit targets shift. The failure shapes differ; neither path is evidence for the other. A responsive implementation that claims “it can be enlarged” has to fill both cells of the matrix.

Where it stops holding

A canvas, game, or image viewer with almost no type will not show much on the font-size path; still test zoom (chrome and tools change). Native apps split into display scale and Dynamic Type — different tools, still two paths, not one. Text baked into images cannot enlarge on either path; split the text out before using the matrix as a pass. User stylesheets and reading mode add a third path that is outside this card’s minimum matrix and must not substitute for zoom or font size. Mail clients support both poorly; crop the matrix to the client rather than importing the web result.

Applying it

• Two acceptance cells on critical flows: browser zoom at 200%; root or system type clearly enlarged (root at 32px, or the OS maximum), with window width held at one common desktop and one common phone size.
• In both cells check overflow, overlap, whether primary actions stay fully visible, and whether body text can only be read by dragging sideways.
• Heights, line-heights, and icon boxes locked in px should move to units that follow type, then both cells are re-run.
• How to check: walk the same main task in both cells. A pass in one and clipping or blocked actions in the other means responsive implementation has not passed. An acceptance pack with zoom shots and no font-size shots is a missing cell.

Related

• Same group: R3.03.1 Breakpoints should key off the container, not only the viewport · R3.03.2 Content-driven layout cuts the number of breakpoints
• Nearby: J2.11 Reflow and text resize · R3.11 Responsive implementation and breakpoint strategy
• Search terms: browser zoom versus font size · text resize testing · responsive acceptance matrix