1.4.10Level AA Perceivable

Reflow

At 320 CSS pixels wide, content has to work without scrolling in two directions at once. That width is what a 1280-pixel window becomes at 400% zoom. The mirror requirement, for content that scrolls sideways such as vertical Japanese, is 256 pixels of height. Stacking into a single column is how most sites get there. It is not the rule, and the standard says so plainly. A carousel that scrolls sideways inside a page that scrolls down passes, as long as each panel fits 320 pixels. A two-column diff view passes, as long as each column does. What the rule kills is dragging the page sideways to read every single line.

Why it matters

Reading at high magnification while scrolling in two directions means pulling the page right and then back left for every line you read. Picture reading this paragraph that way. Good responsive design already delivers reflow as a side effect, which makes this the rule where mobile-friendliness and accessibility turn out to be the same discipline wearing two names. One thing it does not ask for is bigger text. You can shrink type at narrow widths to help content fit and still satisfy 1.4.4 through zoom, because the two rules measure different things.

Who this rule protects

Low-vision users browsing at high magnification meet this every day, and 400% zoom is an ordinary setting rather than an extreme one. Small-screen users get the same layout for a different reason. Anyone with a browser window docked to half a display is closer to the test viewport than they think, since 960 pixels at 300% zoom is already 320.

How to check it yourself

Narrow the browser window to 320 pixels wide rather than zooming, where you can. Zooming a 1280-pixel window to 400% leaves you about 318 by 236, once the scrollbar and the browser's own furniture take their share. That is a slightly harder test than the rule asks for.
Read through the key pages and confirm no line of text needs sideways scrolling to finish.
Check what is causing any horizontal scrollbar. Maps, diagrams, video, games, presentations and data tables are allowed to scroll both ways. The content beside them is not.
Check inside excepted content too. A data table may scroll in two directions and its individual cells still have to reflow.
Check the furniture around a table, meaning its heading, its search box and its pagination. None of that inherits the table's exception.
Look for long unbroken strings, such as a pasted web address or an API key, which force a whole page sideways on their own.
Confirm nothing has disappeared. Content available at a wide viewport has to still be reachable at 320, whether repositioned or tucked behind a control.
Check sticky and fixed elements at 400% and see how much reading space is left underneath them.

Failures we see most often

A fixed-width layout forces side-to-side scrolling for every single line once the zoom level gets high enough.
A modal extends wider than the viewport, so the Confirm button ends up off screen where nobody can reach it.
A wide table spills outside its container and drags the entire page sideways along with it.
A pasted web address in body text refuses to break, so one string sets the minimum width of the whole page.
Content that was on the page at desktop width is gone at 320, with no control anywhere to bring it back.
A sticky header and a cookie banner between them take most of the height at 400%, leaving a reading strip a couple of lines deep.
A label and its input are locked side by side and cannot stack, so that one row sets a width nothing else can go below.

Who this one is for

Read from this rule's own note above, so the grouping and the note cannot disagree.

Low visionpeople who can see the screen but not easily

How this one is tested

We list 1 ACT rule against 1.4.10. Each one defines exactly what a checker looks at, which is how automated tools decide what to flag. Each one also checks a slice, so passing every rule here is not the same as meeting the criterion, and a rule can be proposed rather than approved or need a person to finish it. The note beside each says which.

Meta viewport allows for zoomA tool can check this

How to fix it

Build responsive layouts with flexible grids and flexbox, and let media queries stack what needs stacking. Solid responsive work gets you most of the way here.
Give wide tables and code blocks their own horizontal-scroll container, so the page around them never has to scroll sideways itself.
Break long strings, with word-break or by inserting break opportunities, so one web address cannot set the page's width.
Let label and input rows wrap on narrow widths instead of holding their side-by-side arrangement.
Unstick sticky headers and footers at narrow viewports, or let the user dismiss them, so the reading area survives the zoom.
Where content is truncated to fit, link to a page showing it in full, or give a control that reveals it in place.

Step-by-step fix guides (11)

Routes and related guidance (10)

Documented failures (1)

F102: Do not let content vanish when the page reflows

Passes vs. fails

A general illustration of the pattern rather than a test of 1.4.10. Passes: one column, no side-scroll. Fails: every line scrolls sideways.

Passes

Content stacks into a single column at 400% zoom, and only the data table scrolls sideways, contained inside its own frame.

Fails

At 400% zoom, every sentence on the page requires scrolling right and then back left just to finish reading it.

In audits and lawsuits

We test every audited page at 400% zoom. Sites on solid responsive foundations mostly pass, and the findings cluster in modals, data tables, third-party embeds and sticky furniture nobody tested narrow. Sticky headers, cookie banners and chat widgets are the most consistent of those. A bar that took 60 pixels of a tall window can take a third of what is left at 400%. Two things stop a finding being raised where it should not be. A page-level horizontal scrollbar caused by excepted content passes, so long as everything else reflows. And relocating content is not losing it, so a navigation collapsing into a menu button is fine.