Browser zoom and text-only resize are different magnification paths and must be tested separately

What it is

Some people hit the browser plus key and scale the page as a picture. Some people only raise type in settings, leaving layout images and gaps at their original pixels. Those two paths are page zoom and text-only resize. They rewrite different pixels and fail in different places, so acceptance has to walk both; one pass cannot stand in for the other.

Low-vision users use both: some live on Ctrl / Cmd plus, some only change the OS or browser default font, some stack the two. Testing the plus key alone tests only one of those lives.

Why it happens

Page zoom enlarges CSS pixels and narrows the viewport in proportion: images, type, gaps and shadows grow together, as if the layout had been stuffed into a thinner window. Text-only resize changes font metrics alone: the type box grows taller and wider, while pixel-stated columns, icons and fixed-position chrome can sit still. The first path forces reflow at a narrow viewport; the second forces a mismatch in which type grows and slots do not.

The user agents differ too. Page zoom is the browser’s zoom factor. Text-only resize may come from “zoom text only,” OS font scaling, a user stylesheet, or a reader view. A column hard-coded in px may still look packed under the plus key, then have its heading blow through a button when only type grows. Conversely, a layout that reflows at 320 px wide may never hit the breakpoint the author expected if the user raises type to 200% in a still-wide window.

Studying it

Run two operations on the same pages: keep a typical window width and use browser zoom only; then reset zoom and raise the default font to about 200%. Log failures unique to each path; do not merge them into one “magnification” score.

Independent variables: zoom kind (full page / text only), magnification factor, whether window width changes with it. Dependent variables: breakage kinds unique to each path (overlap, misalignment, control/label decoupling, media queries that never fire).

Firefox “zoom text only” and Chrome’s font settings are not the same implementation; cover at least one text-only path and one full-page path. In WCAG-EM sampling, mark the two magnifications as distinct test conditions so the records cannot substitute for each other.

Where it stops holding

Native apps often expose only the system font size, with no browser plus key; “test both” then collapses to testing the system size. PDF, canvas and map viewports do not run page CSS, so the page-versus-text split does not apply. Reader view discards the original layout and measures the reader, not the product. Dragging the window narrow approximates “viewport got thinner”; it does not approximate “type and images grew together.”

Applying it

• Write “browser plus” and “type only” as two acceptance conditions. Do not log them as a single “200% zoom.”
• Do not assume breakpoints will fire under zoom: text-only resize can leave the window wide, so columns you expected to stack may not.
• Size type in relative units, and let control slots grow with the type box so type cannot outrun its slot.
• How to check: walk the primary path at Cmd/Ctrl 200%, then restore 100% and walk it again with only the browser default font raised. Record issues unique to each pass. Missing a pass means zoom was not tested.

Related

• Same group: J2.11.2 High magnification requires content to reflow into a single column rather than relying on horizontal scrolling · J2.11.3 After zoom, interactive elements must not be squeezed into accidental activation · J2.11.4 Text baked into images cannot scale with page text
• Nearby: J2.02 Text Resize · J2.07 Low Vision and Screen Magnification · J5.13 System Accessibility Settings
• Search terms: page zoom · text-only resize · text zoom versus browser zoom