Field Notes

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.

  • zoom
  • layout
  • css

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, not width. A 720 pixel column is max-width: 720px; width: 100%.
  • No fixed heights on anything that holds text. Let text grow. Use min-height if 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 at 48em fires at the right moment when the user zooms, because em breakpoints scale with text size. One at 768px does not.

Test it in thirty seconds

  1. Open the page on a desktop browser.
  2. Zoom to 400 percent. Most browsers stop there.
  3. 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.

Open the companion lab

Spotted something this note gets wrong?

Corrections and better examples are the best kind of message.

Send a correction