The Sentence That Never Ends
She has low vision, and she reads the news the way she reads everything else online — browser zoom set to 300%, comfortable, legible, no strain. She opens a headline story, starts the first paragraph, and the trouble begins immediately.
The site's layout was built at a fixed width, designed to look right on one screen size and never touched again. At 300% zoom, a single line of body text now stretches far past the right edge of her window. She reads to the edge, scrolls right to catch the rest of the sentence, scrolls back left to find the start of the next line, and repeats. A five-minute article becomes a twenty-minute exercise in horizontal scrolling, and by paragraph three she gives up and leaves.
Nothing on that page was broken in the traditional sense. The HTML validated. The images loaded. The text was even a decent, readable font. The layout simply never accounted for the fact that people zoom — and two WCAG success criteria exist specifically to stop this from happening.
1.4.4 Resize Text: The 200% Floor
1.4.4 Resize Text is a Level AA success criterion from the original WCAG 2.0 standard, and it sets a clear, testable bar: text must be resizable up to 200% without loss of content or functionality, and without requiring assistive technology to do it.
Two details matter here that get misunderstood constantly:
- This means browser zoom — the standard Ctrl/Cmd + Plus most browsers ship with — not a custom font-size toggle built into the page. A site can offer its own text-size widget as a bonus feature, but that widget does not satisfy 1.4.4. The criterion is about what happens when a real user, with a real browser, zooms in the way browsers have always supported.
- "Without loss of content or functionality" is the pass/fail line. If text overlaps other text, if a button gets cut off and can no longer be clicked, if a form field's label disappears behind the input above it — that's a fail, even if the text itself is technically bigger and technically readable in isolation. Bigger-but-broken is still broken.
Picture a pricing table that looks tidy at 100% zoom. At 200%, the price and the "Buy Now" button — set with fixed pixel positioning — start overlapping the plan description above them. The text got bigger exactly as requested. The page also became impossible to purchase from. That's a 1.4.4 failure.
1.4.10 Reflow: The Criterion That Goes Further
WCAG 2.1 added 1.4.10 Reflow, a Level AA criterion that picks up where 1.4.4 leaves off. Where 1.4.4 asks "can text get bigger without breaking," 1.4.10 asks a sharper question: can the whole layout survive being viewed at 320 CSS pixels wide?
That 320px figure isn't arbitrary. It maps to two real-world scenarios at once:
- A standard 1280px-wide desktop browser window, zoomed to 400%.
- A typical mobile phone screen, viewed normally.
The requirement is that content at this width must be usable without two-dimensional scrolling. Vertical scrolling is completely fine — expected, even, since content stacks as it narrows. What fails is needing to scroll horizontally to read a line of text, reach a button, or find a form field. If the woman in the opening story had been testing 1.4.10 conformance instead of just trying to read the news, that endless left-right scroll to finish a single sentence is the exact failure mode the criterion was written to eliminate.
1.4.10 does carry specific, listed exceptions for content that genuinely needs two dimensions to make sense: data tables, images, maps, diagrams, and video. Nobody expects a spreadsheet or a world map to reflow into a single column — reading it that way would destroy the information it's conveying. But those exceptions are narrow. A navigation bar, a pricing grid built from <div>s, or a row of icon buttons don't get to claim the table exception just because a developer laid them out with display: table years ago.
Two Criteria, Overlapping but Different Audiences
It's worth being precise about who each criterion protects, because they're not identical:
- 1.4.4 primarily serves people with low vision who rely on standard browser zoom to read comfortably — no special software, just the zoom control every browser already has.
- 1.4.10 covers that same group and extends further to people using dedicated screen magnification software, which can push magnification well past 400%. It also happens to be one of the more direct proxies for "is this actually mobile-friendly," since a 320px viewport is functionally a phone screen.
A site can technically pass 1.4.4 — text gets bigger, nothing overlaps at 200% — and still fail 1.4.10 badly at 400%, because the failure modes compound as the viewport shrinks further. Testing only at 200% and calling the job done misses exactly the failures 1.4.10 exists to catch.
What Actually Causes Reflow Failures
In practice, the same handful of coding patterns show up again and again:
- Fixed pixel widths on containers. A
width: 960pxdiv doesn't care how narrow the viewport gets — it just forces a horizontal scrollbar into existence. Relative units — percentages,rem, or modern CSS functions likemin()andclamp()— shrink and grow with the viewport instead of fighting it. - Fixed-height text containers with
overflow: hidden. When the container can't grow to fit text at a larger size, the content doesn't reflow — it gets clipped or hidden entirely. That's not a rendering hiccup, it's a content-loss failure under 1.4.4 and 1.4.10 both. - Horizontally-scrolling nav bars and tab strips. These are frequently designed and QA'd once, at one zoom level, and never revisited. They're also one of the most common ways a page technically "reflows" while quietly requiring the exact two-dimensional scrolling 1.4.10 forbids.
- Absolutely-positioned elements that ignore their parent. An element positioned with hardcoded top/left coordinates doesn't reflow with the container around it — it just sits there, increasingly misaligned, as everything else adjusts.
The Ten-Minute Test You Can Run Right Now
You don't need specialized tools to catch most of this. Here's the manual check:
- Open your homepage and your most important conversion page (checkout, signup, booking form).
- Zoom your browser to 400%.
- Try to read every line of body text from left edge to right edge without scrolling sideways.
- Try to operate every button, link, and form field without a horizontal scrollbar appearing.
- Note anywhere text overlaps, gets clipped, or a control becomes unreachable.
If you find yourself scrolling right to finish a sentence, or a "Submit" button disappears behind a sticky header, you've just found a live 1.4.10 or 1.4.4 failure — the same one that pushed the low-vision reader in our opening story off the page.
The Good News: This Overlaps With Doing Responsive Design Right
Here's the part that should be genuinely reassuring. Of everything in the WCAG spec, reflow is one of the criteria with the cleanest overlap with plain, modern, good responsive design. A site built mobile-first, using fluid layouts with flexbox or grid and relative sizing units, will typically pass 1.4.10 close to automatically — because the entire point of that approach is a layout that adapts to whatever width it's given.
The sites that fail are almost always the ones retrofitted from a fixed-width, desktop-only design that someone later tried to "make responsive" with patches and media-query band-aids instead of a real fluid foundation. Those retrofits tend to fail 1.4.10 in multiple places at once, because the underlying architecture was never built to bend in the first place.
The Bottom Line
1.4.4 sets the floor — text must resize to 200% via standard browser zoom without losing content or function. 1.4.10 raises the bar considerably further — the entire layout must hold together at a 320px-equivalent viewport, at up to 400% zoom, without ever forcing a user to scroll in two directions just to read a sentence or click a button. Between them, these two criteria protect people with low vision, people using magnification software, and — as a byproduct — every mobile visitor your site has.
Fixed pixel widths, clipped containers, and unreviewed horizontal nav bars are fixable. They're also exactly the kind of failures that hide in plain sight until someone actually zooms in and tries to read the page the way a real user does.
Don't wait for a user to discover your reflow failures for you. Explore our resources and get your site tested against 1.4.4 and 1.4.10 before the next zoomed-in visitor scrolls sideways off your page for good.