400 percent zoom is a layout test, not an edge case
Zoom a desktop page to 400 percent and you get a 320 pixel wide viewport. If the page cannot reflow into that, it has failed for everyone who needs large text.
Press Ctrl or Cmd and plus until the browser says 400 percent. A 1280 pixel wide window is now, as far as the page is concerned, 320 pixels wide. Everything that was designed for a desktop has to live in the width of a small phone.
This is not an edge case. It is how a large number of people with low vision read the web every day. Browser zoom is the assistive technology that needs no download and no training, and it works exactly as well as the page lets it.
Two ways to fail
The page does not reflow. Fixed widths, fixed heights, and layouts that assume a minimum viewport push content off the right edge. Now reading a paragraph means scrolling right and back for every line. WCAG calls this reflow and asks that content at 320 pixels wide not require two-dimensional scrolling, except for things that genuinely need it like maps and data tables.
The page reflows but breaks. Text overlaps. A sticky header grows until it covers half the screen. A modal's close button sits below the fold with no way to reach it. Two columns become one column with the second column's content first. Text in a fixed-height box gets clipped mid-sentence.
The second kind is worse because it looks like it works until you try to use it.
The one line that disables it all
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">
user-scalable=no and maximum-scale=1 tell mobile browsers to refuse pinch zoom. Some browsers now ignore it, most do not. It is added to stop a layout from "looking wrong" when zoomed, which is exactly the problem that should be fixed instead. The agent ruleset treats it as a blocker, AW-STRUCT-003, because it removes the one tool the reader had.
What reflow-friendly CSS looks like
Most of it is what you already do for phones, applied honestly.
- Widths in percent or in content units, with
max-width, notwidth. A 720 pixel column ismax-width: 720px; width: 100%. - No fixed heights on anything that holds text. Let text grow. Use
min-heightif you need a floor. - Grids that collapse.
grid-template-columns: repeat(auto-fit, minmax(16rem, 1fr))becomes one column on its own when the space runs out. No breakpoint required. - Sticky elements with a size limit. A sticky header is fine at 60 pixels. At 400 percent it is 240 pixels, which is most of the screen. Un-stick it below a width, or cap its height.
- Spacing in
rem, not pixels tied to a layout you imagined. Zoom scales rem. It scales pixels too, but a layout built from rem reflows more predictably. - Breakpoints in
em. A media query at48emfires at the right moment when the user zooms, because em breakpoints scale with text size. One at768pxdoes not.
Test it in thirty seconds
- Open the page on a desktop browser.
- Zoom to 400 percent. Most browsers stop there.
- Scroll down the page using only the vertical scrollbar or the arrow keys.
Any horizontal scrollbar on body text is a reflow failure. Any text you cannot read because something covers it or clips it is a breakage. Any control you cannot reach is a blocker.
Then open the responsive mode in developer tools and set the width to 320. It is the same test, and it is faster to repeat while you fix things.
Why this is a layout test
Reflow at 400 percent is the same discipline as responsive design, with one extra constraint: it has to hold at a width you did not choose and with a text size you did not choose. A layout that survives it is a layout that was honest about its content. That is what the Zoom to 400 Percent lab is: a page you have to make reflow, and the CSS to take with you when you do.