What Happens to Your Page at 200 Percent Zoom, and Why the Standard Actually Tests 400

What actually happens to my site when someone zooms to 200 percent?

Usually something embarrassing. A fixed-width card stops fitting, a navigation bar overlaps its own logo, a pricing table starts scrolling sideways, or a sticky header grows until it eats half the screen. None of it shows up in a normal review, because nobody reviews a site zoomed in.

Zoom is the accessibility check with the best ratio of effort to findings I know. It takes about ten minutes, it needs no tooling, and on most B2B sites it finds real problems on the first page you try. It also happens to be a requirement rather than a nicety.

This is what the standard actually asks for, which design decisions break first, and what I change in a layout system so that it keeps working.

What does WCAG actually require about zoom?

Two separate things. Success Criterion 1.4.4 Resize Text says that, except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. Success Criterion 1.4.10 Reflow is about layout, and it is the stricter of the pair.

1.4.4 is mostly about not getting in the way. The W3C explains that scaling content is primarily a user agent responsibility, and that the author's responsibility is to create web content that does not prevent the user agent from scaling the content effectively. In practice that means not hard-coding sizes and containers that refuse to grow.

Both criteria sit at Level AA, which is the level most organisations target and the level most procurement questionnaires ask about. Neither is obscure, and neither is new, which makes the failure rate on ordinary marketing sites all the more striking.

Why is 320 CSS pixels the number that matters?

Because Reflow is defined by width, not by zoom level. 1.4.10 says content must be presented without loss of information or functionality, and without requiring scrolling in two dimensions, at a width equivalent to 320 CSS pixels for vertically scrolling content, or a height equivalent to 256 CSS pixels for horizontally scrolling content.

The W3C's own note explains the translation: 320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels at 400 percent zoom, and 256 CSS pixels is equivalent to a starting viewport height of 1024 CSS pixels at 400 percent zoom. So a criterion that sounds like it is about zoom is really about a very narrow viewport.

That reframing is the useful part for designers. If your responsive design genuinely works at 320 pixels wide, you have most of Reflow already. If your smallest breakpoint is 375 and everything below it was never tested, you probably do not.

Which design decisions break first?

Anything with a fixed dimension, anything absolutely positioned, and anything that assumes two things sit side by side. In my experience the order is consistent: navigation bars, pricing tables, card grids with fixed card widths, sticky elements, and then modals.

Navigation breaks first because it is usually built as a horizontal row that only collapses at a mobile breakpoint the zoom level never triggers. At high zoom on a desktop the viewport is narrow but the browser is still reporting a desktop context to any layout logic keyed to device type rather than available width.

Sticky headers are the cruelest one, because they get worse as zoom increases. A header that occupies a reasonable slice of the screen at normal size can occupy most of it at 400 percent, leaving a strip of content in between. The criterion says content must be usable, and a two-line reading window is not.

What is exempt, and what is not?

Reflow makes an exception for parts of content that require two-dimensional layout for usage or meaning. The W3C gives examples: images required for understanding such as maps and diagrams, video, games, presentations, data tables but not individual cells, and interfaces where it is necessary to keep toolbars in view while manipulating content.

The exception is narrower than people hope. The W3C is explicit that sections of content within a two-dimensional layout, such as each cell within a table, still need to meet the criterion. A data table may scroll in two dimensions. The text inside a cell may not become unreadable.

What this rules out is the common defence that a design is information-dense so the rules do not apply. Density is not one of the listed exceptions. If your layout needs sideways scrolling because it is complicated rather than because it is a map, that is a failure with extra steps.

How do you test this in ten minutes?

Open your most important page in a normal desktop browser window, zoom to 200 percent, and read it start to finish. Then zoom to 400 percent and check whether you ever have to scroll horizontally to read a line. Do both on your homepage, your pricing page, and one long content page.

Write down what breaks rather than fixing as you go. The first pass is a survey, and stopping to fix the navigation means you never reach the pricing table. My own list usually comes out at somewhere between four and eight items per site, and most of them are one property each.

The complementary check is to narrow the browser window to around 320 pixels wide at normal zoom. That is a faster way to see Reflow problems, because it tests the same condition without changing the text size at the same time, which makes it easier to see what is a layout failure and what is a typography failure.

What should you change in the layout system?

Stop sizing things in fixed pixels where a relative unit would do, let containers wrap rather than overflow, and key layout changes to available space rather than to a device assumption. Most fixes are small once the underlying habit changes.

The habit worth adopting is to think about the container rather than the screen. A card that decides its own layout based on how much room it has been given behaves correctly at any zoom level, in any column, on any device, without you enumerating cases. I went through this shift for spacing specifically in replacing fixed padding with container-driven spacing.

The other change is to stop treating the smallest breakpoint as the phone breakpoint. It is the narrow-viewport breakpoint, and high zoom on a large monitor lands in it just as surely as a phone does. Designing that breakpoint as a legitimate layout rather than a compressed afterthought fixes most of the list at once.

Why is this a design problem rather than a developer problem?

Because the decisions that break under zoom are made in the design, not in the build. A layout that requires three columns to make sense will always fight a narrow viewport, and no amount of careful implementation rescues a structure that has no single-column version.

The design decision that matters most is whether each section has an honest linear order. If you can say what comes first, second, and third when everything stacks, the build is straightforward. If the design only works as a composition, someone downstream has to invent the order and will invent it badly.

This sits alongside the other accessibility decisions that are really design decisions, like colour contrast, which I covered in designing accessible text contrast. In both cases the cheap moment to get it right is in the design file, and the expensive moment is after launch.

Does this conflict with a dense, information-rich design?

Less than people assume. Density is about how much you show at once, and Reflow is about whether it can stack. Plenty of dense B2B interfaces reflow perfectly well, because their density comes from tight spacing and clear grouping rather than from fixed side-by-side geometry.

Where the conflict is real, it is usually a comparison table, and the standard has an answer for that. Tables are listed among the examples of content that may require two-dimensional layout, so a table may scroll sideways. The cells inside still have to behave.

My honest position is that most density arguments are really reluctance to design the stacked version. It is more work, it is less fun, and nobody puts it in the portfolio. It is also where a meaningful share of your readers actually are, and increasingly it is where procurement checks, which I touched on in what the European Accessibility Act means for site owners.

What should you do next?

Zoom your homepage to 400 percent right now and try to read the first three sections. If you have to scroll sideways to read a line of text, you have found your first fix, and it will almost certainly be a fixed width somewhere in a container.

After that, run the same check on the page that carries your pricing or your primary conversion. Those are the pages where a layout failure costs something immediately, and they are usually the ones with the most fixed geometry in them.

If you run the check and you are not sure whether what you are seeing is a real failure or an acceptable exception, send me a screenshot at 400 percent and tell me what the section is for. I will tell you how I read it. Let's chat.