WCAG 1.4.10 Reflow: How to Pass the 400% Zoom Test Without Breaking Your Layout

Zoom a typical web page to 400% and watch what happens. The sticky header takes up half the screen. The cookie banner covers the other half. A data table pushes the whole page sideways. Every line of body text needs a horizontal scroll to read.

For many people with low vision, that is just the web. In WebAIM's survey of users with low vision, 44% of respondents reported using browser zoom controls, and 18% enlarged content to more than 400%. (WebAIM) Worldwide, at least 2.2 billion people have a near or distance vision impairment, according to the WHO.

WCAG Success Criterion 1.4.10 Reflow exists for them. It's a Level AA criterion, so it's part of the WCAG 2.1 AA baseline that the European Accessibility Act requires in practice through EN 301 549. This guide explains what it actually requires, the failures we see most, the CSS that fixes them, and how to test.

What SC 1.4.10 requires

The W3C wording, paraphrased: content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions, at:

• a width of 320 CSS pixels for content that scrolls vertically (most web pages), and
• a height of 256 CSS pixels for content that scrolls horizontally (for example, some vertical-script languages or horizontally scrolling interfaces).

The exception: parts of the content which require two-dimensional layout for usage or meaning. (W3C, Understanding SC 1.4.10)

Why 320 pixels?

320 CSS pixels is what a 1280px-wide browser window becomes at 400% zoom (1280 / 4 = 320). It also matches the width of small phone viewports. So one requirement covers two situations: desktop users zooming heavily, and mobile users on narrow screens.

What "without two-dimensional scrolling" means

At 320px wide, a user should be able to read the page by scrolling only vertically. Horizontal scrolling for the whole page, or for blocks of text, is a failure.

What "without loss of information or functionality" means

Reflowing by hiding things doesn't count. If a responsive layout drops the search box, truncates product descriptions with no way to expand them, or removes table columns at small sizes, that's a failure even though nothing scrolls sideways. Moving content behind a menu toggle or disclosure is fine, as long as it's still reachable.

The exception is per part, not per page

This is the most commonly misread part of the criterion. Maps, complex diagrams, video, games, presentations, data tables and toolbars that must stay in view while editing can legitimately need two-dimensional layout. But the exception applies to that part only. A page with a large data table can let the table scroll horizontally within its own container. The rest of the page (headings, paragraphs, navigation, form fields) still has to reflow.

How 1.4.10 differs from related criteria

Criterion	Level	What it tests
1.4.4 Resize Text	AA	Text can be resized to 200% without loss of content or function
1.4.10 Reflow	AA	Layout works at 320 CSS px without two-dimensional scrolling
1.4.12 Text Spacing	AA	Content survives increased line, paragraph, letter and word spacing
2.4.11 Focus Not Obscured (Minimum)	AA (WCAG 2.2)	Focused elements aren't entirely hidden by sticky content

One related failure is worth calling out: blocking pinch-zoom on mobile. A viewport meta tag with user-scalable=no or a low maximum-scale stops users from zooming at all. That's a failure of 1.4.4 Resize Text, and it makes 1.4.10 meaningless on that device. Check your <meta name="viewport"> before anything else:

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

<!-- Fails: blocks zoom -->
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">

The failures we see most, and how to fix them

1. Fixed-width containers

A width: 960px wrapper, or a component with a hard-coded pixel width, is the classic cause of horizontal scrolling.

/* Fails at 320px */
.container { width: 960px; }

/* Reflows */
.container {
  width: min(100% - 2rem, 60rem);
  margin-inline: auto;
}

Use max-width or min() rather than width, and size components with relative units.

2. Multi-column layouts that don't collapse

Grids with a fixed number of columns stay side by side, squeezing or overflowing content.

.cards {
  display: grid;
  gap: 1rem;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 16rem), 1fr));
}

The min(100%, 16rem) part matters: without it, a 16rem minimum can still overflow a 320px viewport once padding is added. For components that live in different-sized slots, container queries let the component respond to its own width rather than the viewport's.

3. Sticky headers, footers and banners that eat the viewport

At 400% zoom, a 256px-tall viewport has very little room. A sticky header, a sticky "add to cart" bar, a cookie banner and a chat launcher can leave almost nothing visible, and can hide the focused element (a 2.4.11 failure as well).

Fixes:

• Make headers sticky only above a certain viewport height, using a media query such as @media (min-height: 30em) { header { position: sticky; top: 0; } }.
• Let banners collapse to a single line, or become part of the page flow at small sizes.
• Add scroll-padding-top equal to any sticky header height, so focused and anchored elements aren't hidden underneath it.

4. Navigation that becomes unreachable

Horizontal menus often overflow at 320px. Off-canvas menus sometimes can't be scrolled once open, so the last links are unreachable.

Fixes: switch to a disclosure ("Menu") button at small widths, make the open menu panel scrollable (overflow-y: auto with a height based on dvh), and confirm every item can be reached by keyboard and by touch.

5. Wide data tables

Data tables are a legitimate exception, but only within their own container. Don't let them push the page sideways.

<div class="table-scroll" role="region" aria-labelledby="prices-caption" tabindex="0">
  <table>
    <caption id="prices-caption">Plan prices by region</caption>
    ...
  </table>
</div>

.table-scroll { overflow-x: auto; }

The tabindex="0" and region label let keyboard users focus the container and scroll it with the arrow keys. For simple two- or three-column tables, consider a stacked layout at small widths instead.

6. Long unbroken strings

URLs, email addresses, product codes and long words in languages such as German can force a container wider than the viewport.

.prose { overflow-wrap: anywhere; }

Use hyphens: auto with a correct lang attribute for natural-language text where your design allows it.

7. Modals and dialogs that can't scroll

A dialog with a fixed height and overflow: hidden will cut off its own content at 400% zoom, often including the buttons that close or submit it.

dialog {
  max-height: 100dvh;
  max-width: 100vw;
  overflow-y: auto;
}

8. Fixed heights and clipped text

Cards, buttons and banners with a fixed height and overflow: hidden clip text once it wraps onto more lines. Truncation with an ellipsis is a loss of information unless the full text is available another way. Prefer min-height and let content grow.

9. Absolute positioning

Absolutely positioned tooltips, badges and labels often overlap content or move off-screen at narrow widths. Position them relative to their component, and make sure tooltips stay within the viewport and can be dismissed.

How to test reflow in five minutes

There are two ways to test, and it's worth doing both.

Method 1: real browser zoom. Set your browser window to 1280px wide, then zoom to 400%. This is the most realistic test, because it reproduces what zoom users actually experience, including how your breakpoints respond.

Method 2: a narrow viewport. In browser developer tools, set a responsive viewport of 320 x 256 CSS pixels. This is quicker for checking specific components.

For each key page template, check:

1. Can you read all body text by scrolling vertically only?
2. Is every piece of content and every function still available (search, filters, menu items, form fields, buttons)?
3. Do sticky elements leave enough of the screen visible to use the page?
4. Is the focused element always visible when you tab through?
5. Do data tables, maps and other genuine 2D content scroll within their own containers, without dragging the page sideways?
6. Do dialogs scroll, and can you reach their buttons?

There's an ongoing discussion within the W3C's WCAG community about whether the 320px width and 256px height conditions should be evaluated independently or together. (W3C WCAG discussion #5094) Since real zoom shrinks both dimensions at once, testing with real 400% zoom catches the failures that matter to users either way.

Automated scanners catch very little of this: reflow is a layout behaviour, not a markup property. It has to be checked by a person, at the template level, every time a layout changes. Our guide to building a WCAG testing tool stack covers where manual checks like this fit.

Where reflow fits in an EAA programme

The EAA has applied since 28 June 2025 to in-scope consumer products and services, and EN 301 549 carries WCAG 2.1 AA, including 1.4.10, into that obligation. Reflow is also one of the criteria regulators and auditors can test quickly: it takes a browser and a zoom shortcut. That makes it a sensible early target.

The most effective fix is structural. If your design system's layout primitives (containers, grids, cards, dialogs, tables, headers) reflow correctly, every page built from them inherits that. See Your Design System Is Your Accessibility Infrastructure for how to make that stick, and our colour contrast and focus appearance guide for the other low-vision criteria worth fixing at the same time.

Checklist

• Viewport meta tag doesn't block zoom (user-scalable=no, maximum-scale=1)
• No fixed-width containers; layouts use max-width, min() and relative units
• Grids collapse to one column at 320px
• Sticky headers, bars and banners don't eat the viewport at 400% zoom
• scroll-padding-top set for sticky headers; focused elements never fully hidden
• Navigation reachable and scrollable at 320px
• Data tables scroll in a focusable, labelled container
• Long strings wrap (overflow-wrap: anywhere)
• Dialogs scroll and keep their buttons reachable
• No fixed heights that clip text; no truncation without access to the full text
• Every key template tested at real 400% zoom on a 1280px window

The bottom line

Reflow is one of the most visible WCAG criteria: anyone can test it with a keyboard shortcut. The fixes are mostly ordinary, well-understood CSS. What makes teams fail is not difficulty but habit: fixed widths, sticky everything, and testing only at the breakpoints designers drew. Test at 400% zoom, fix the layout primitives once, and the people who rely on zoom will be able to use your site the way everyone else does.

This article is general information, not legal advice.