Responsive design and accessible design overlap, but they are not the same thing. A layout can pass every breakpoint your QA team tests on real phones and still fail WCAG reflow responsive requirements, because the criteria measure something most teams never check: how content behaves when a sighted user with low vision zooms a desktop browser to 400% or bumps text size to 200%. Two Level AA success criteria govern this directly: 1.4.10 Reflow and 1.4.4 Resize Text. Disabling pinch-zoom on touch devices is a documented failure of 1.4.4, which is why it gets its own section below.
These criteria are squarely in scope for the European Accessibility Act, which applies from 28 June 2025 with WCAG 2.2 Level A and AA as its baseline through EN 301 549. This guide explains what each criterion actually measures, the CSS patterns that break them, and how to test reflow without guessing.
1.4.10 Reflow: a single column at 320 CSS pixels
Reflow (Level AA) requires that content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions, at a width equivalent to 320 CSS pixels. The 320px figure is not arbitrary: it is what you get when a 1280px-wide viewport is zoomed to 400%. So the real-world test is a desktop user zooming in, not a phone, though a 320px phone exercises the same code path.
The core rule is one-dimensional scrolling. Vertical content (an article, a feed) may scroll vertically but must not also force horizontal scrolling. Content that genuinely needs two dimensions, such as a data table, a code block, or a map, is exempt and may scroll the other way. The failure everyone hits is the accidental horizontal scrollbar: a fixed-width element wider than the viewport drags the whole page sideways.
Common culprits:
- Fixed pixel widths on containers (width: 600px instead of max-width: 600px). Swap to max-width so the element shrinks below 320px.
- Large unbreakable strings such as long URLs, API keys, or hashes that push width out. Apply overflow-wrap: break-word to text containers.
- Off-canvas menus and modals that are positioned but never constrained, leaving a phantom scroll region to the right.
- min-width on flex or grid children that refuses to shrink. Add min-width: 0 to flex items so they can collapse below their content size.
- Negative margins or 100vw widths that ignore the scrollbar and overflow by a few pixels.
A fast smoke test: set the viewport to 320px in DevTools device mode and watch for a horizontal scrollbar, or query the DOM for elements whose scrollWidth exceeds the viewport. AccessScan flags reflow overflow automatically, so you can run a free scan to see which elements break at 320px before you start fixing CSS.
1.4.4 Resize Text: 200% without breaking the page
Resize Text (Level AA) requires that text can scale up to 200% without loss of content or functionality. This is distinct from reflow. Reflow is about page width; resize text is about text-only enlargement. The classic way to test it is the browser's text-only zoom (Firefox offers a dedicated 'Zoom text only' option), or raising the root font size and seeing whether the layout copes when text doubles but images do not.
The pattern that passes is relative units. Set font sizes in rem or em, and, critically, set the heights of text-bearing containers in relative units too, or leave them to grow. The pattern that fails is a fixed-height box around scalable text.
A button declared height: 40px with font-size: 1rem looks fine at default size. Double the text and the glyphs are clipped or spill out, because the box cannot grow. Use min-height plus vertical padding instead, so the container expands with its contents. The same applies to navigation bars, badges, and any chip or pill where designers pinned an exact height.
Reflow and resize behaviour also interacts with 1.4.12 Text Spacing (AA), which requires the page to survive user-applied increases to line height and letter spacing. The same fixed-height boxes tend to fail all three at once, so if you fix container heights properly you usually clear reflow, resize, and text spacing together. Watch -webkit-line-clamp truncation too: hiding text behind an ellipsis can fail if the clamped text is the only place that information lives.
Never disabling zoom: the user-scalable trap
The single most avoidable failure in this area is a meta viewport tag that disables pinch-to-zoom. You have seen it copied from old Stack Overflow answers: a viewport tag with maximum-scale=1 and user-scalable=no. Those two values prevent a user from zooming the page on a touch device. For a person with low vision who relies on pinch-zoom to read, that is a hard barrier, and it is treated as a failure of 1.4.4 Resize Text on mobile.
The fix is to delete those two values entirely. The correct, accessible tag is simply width=device-width, initial-scale=1. Do not cap maximum-scale, and never set user-scalable=no. Modern iOS Safari ignores user-scalable=no in many cases, but Android browsers and embedded webviews still honour it, so you cannot rely on the platform to save you.
Watch for the same anti-pattern hiding in JavaScript: event listeners that call preventDefault() on touchmove or gesturestart to build custom pan-and-zoom, and CSS touch-action: none applied too broadly. Both can suppress the browser's native zoom. If you ship a framework starter or a CMS theme, audit its default head template, because this failure is almost always inherited, not authored.
Testing reflow and resize without guessing
A repeatable manual pass
Set your browser window to 1280px wide and zoom the page to 400% (Ctrl/Cmd and the plus key, four to five presses). The content should collapse to a single column with only vertical scrolling. Then, separately, use text-only zoom to 200% and confirm nothing clips. Finally, on a real phone or in device emulation, pinch to zoom and confirm it actually responds. These three checks map to 1.4.10, 1.4.4, and the zoom-disabling failure.
Where automation helps
Automated tooling reliably catches the deterministic failures: a user-scalable=no in the viewport tag, an element whose scrollWidth overflows at 320px, fixed pixel widths on layout containers. It cannot judge whether clamped text loses meaning, which still needs a human. Pair an automated scan with the manual pass above, and confirm the underlying AA requirements against the full WCAG success criteria reference so reflow and resize edge cases do not slip past review.
Why this matters for EAA and EN 301 549
Reflow, Resize Text, and zoom are not niche. They sit in WCAG's Perceivable principle at Level AA, which means they are part of the conformance baseline that EN 301 549 references and that the European Accessibility Act adopts for in-scope products and services: e-commerce, banking, e-books, electronic communications, and self-service terminals among them. National laws inherit the same bar: Germany's BFSG, France's RGAA, and Italy's Legge Stanca all align to EN 301 549 and therefore to these criteria.
The encouraging part is leverage. The fixes (max-width instead of width, relative units, min-height instead of height, and a clean viewport tag) are small, mechanical, and tend to resolve several criteria at once. See how the obligations map to the European Accessibility Act, then work through a structured accessibility checklist so reflow and resize do not slip past your next release.