January 24, 2022 · reala11y team

Reflow and zoom to 400% (WCAG 1.4.10) on WordPress

WCAG 1.4.10 Reflow asks your content to survive 400% zoom with no horizontal scrolling. Here's what that means for WordPress themes, and the viewport mistake to avoid.

A surprising number of people read the web at 200% or 400% zoom. Some have low vision; some are reading on a phone held at arm’s length; some just bumped the zoom and never put it back. When your layout breaks at that magnification — content disappearing off the right edge, two scrollbars fighting each other — those readers are the ones who pay for it. WCAG Success Criterion 1.4.10, Reflow, is the rule that says your content should hold together when it’s enlarged. It is Level AA, so it sits inside the conformance bar most legal and procurement frameworks point at.

The good news for WordPress sites: a well-built responsive theme already passes 1.4.10 most of the time. The bad news: a handful of common habits quietly break it, and one of them is a single attribute in your <head>.

What 1.4.10 actually requires

The criterion asks that content reflow into a single column without loss of information or functionality, and without requiring scrolling in two dimensions, down to a viewport of:

320 CSS pixels wide for content laid out vertically (the usual case), and
256 CSS pixels tall for content laid out horizontally.

Why 320px? Because 1280px at 400% zoom collapses to a 320px-wide viewport. So “survives 400% zoom on a desktop” and “works on a narrow phone” are, mathematically, the same test. If your site is genuinely responsive down to a small phone, you have most of Reflow handled already.

The phrase that matters is scrolling in two dimensions. Vertical scrolling is fine and expected. What fails is when a reader has to scroll horizontally to get to content — because the page didn’t reflow, it just got wider than the screen.

There are sensible exceptions: things that genuinely need two-dimensional layout, like data tables, large images, maps, and code samples, may scroll horizontally. You don’t have to mangle a wide table into a single column.

How to test it in two minutes

You don’t need special tooling to find Reflow failures.

Open the page on a desktop browser.
Press Ctrl/Cmd and + until the zoom reads 400%.
Watch for a horizontal scrollbar and for content that’s cut off on the right.

If the page collapses cleanly into one readable column, you’re in good shape. If a hero section, a wide table wrapper, or a fixed-width element forces a sideways scroll, you’ve found your issue. The narrow-device emulator in your browser’s DevTools (set the width to 320px) is the same test by another route.

Where WordPress sites trip up

In rough order of how often we see it:

Fixed widths in pixels. A width: 1100px (or a min-width) on a container, a custom block, or an embedded element refuses to shrink, so it punches out of the viewport at high zoom.
overflow-x: hidden as a “fix.” Hiding the horizontal overflow stops the scrollbar but doesn’t stop the content from being clipped — readers just lose whatever ran off the edge. That’s masking the failure, not fixing it.
Wide tables with no wrapper. A data table is an allowed exception, but it should scroll inside its own container, not blow out the whole page layout.
Absolutely positioned decorations placed with pixel offsets that don’t move when the layout narrows.
Page-builder rows locked to a fixed pixel width instead of a percentage or a fluid grid.

Build for reflow with relative units

The durable fix is to express sizes in relative units so the layout can adapt instead of insisting on one dimension.

/* Containers cap their width but never demand it. */
.container {
  width: 100%;
  max-width: 70rem;   /* a ceiling, not a fixed size */
  margin-inline: auto;
  padding-inline: 1rem;
}

/* Media never overflows its parent. */
img,
video,
iframe {
  max-width: 100%;
  height: auto;
}

/* Wide tables scroll inside their own box, not the page. */
.table-wrap {
  overflow-x: auto;
}

Prefer max-width over width, percentages and rem/em over fixed px, and let flexbox or grid wrap. Reserve horizontal scrolling for the genuine exceptions, and confine it to that element’s own container.

The viewport mistake to avoid

Here is the one that catches people, and it lives in a single line of your theme’s <head>:

<!-- This breaks zoom. Don't ship it. -->
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no, maximum-scale=1">

user-scalable=no and a low maximum-scale disable pinch-to-zoom on mobile. That doesn’t just annoy people — it removes the very mechanism low-vision users rely on, and it’s a direct WCAG 1.4.4 / 1.4.10 failure. The correct tag is simply:

<meta name="viewport" content="width=device-width, initial-scale=1">

If you didn’t write your theme’s header, you may not know this tag is even there. Some older themes, and a few “app-like” templates, still ship the zoom-blocking version. Search your theme for user-scalable and maximum-scale and strip them.

This is exactly the kind of thing a code-level tool can catch and correct, and exactly the kind of thing an overlay widget cannot — an overlay paints on top of the page; it doesn’t rewrite the <head> your browser actually parses. reala11y works at the source: it flags a zoom-blocking viewport tag and can restore pinch-zoom by removing user-scalable=no and maximum-scale from the meta tag, so the markup your real visitors receive is the thing that changed.

Where automated tooling fits — and where it doesn’t

A scanner can spot a zoom-disabling viewport tag with high confidence, and that’s a clean, automatable win. Detecting that a layout survives 400% zoom is harder — rendered reflow is one of the things a human eye still judges best, by doing the two-minute zoom test above. The honest framing we hold to: automated tools, ours included, detect roughly 30–40% of WCAG issues by criteria, and the rest needs a person.

The honest takeaway

Reflow rewards the work you’ve probably already done. If your theme is truly responsive, you’re most of the way there. Cap widths instead of fixing them, let media shrink, give wide tables their own scroll box, and — above all — never disable zoom in your viewport tag. Do that, and you’re moving toward WCAG 2.2 AA conformance on this front the right way: by letting readers size the page to their own eyes.