Have you ever visited a page that looks fine at first, but when you zoom in, you have to scroll sideways just to read the content? Or maybe you’ve had to zoom in and out to see everything? We still see this during reviews, even on sites that claim to be “responsive.”

WCAG 2.1 Success Criterion 1.4.10 (Reflow) is the WCAG requirement meant to prevent that. It says digital content needs to adapt to different screen sizes, eliminating the need for horizontal scrolling—even at 400% zoom—without losing functionality or readability.

But because a desktop screen size is defined as 1280×1024 pixels, the criterion effectively requires your site to adjust to fit within a 320×256-pixel frame. That just happens to match older phone widths, so we get sites that work on small mobile devices without requiring two-dimensional scrolling to view content on a page.

It helps to treat this as a zoom issue first. Breakpoints matter, but zooming makes the viewport smaller while users still expect everything to work the same. Kind of nice, right? So don’t write off older phone widths—test across screen sizes.

What WCAG 1.4.10 Reflow Requires

1.4.10 Reflow is about layout adaptability under constraints. When the viewport gets narrow, whether from device size, split-screen, or browser zoom, the page should reorganize so standard content fits within the visible area. Users should not have to scroll in both directions to read or interact with the site’s content.

WCAG points to a width equivalent to 320 CSS pixels for vertically scrolling pages. Testing at 400% zoom is common because the viewport width shrinks as zoom increases. Zoom itself is not the requirement. The requirement is the experience at an equivalent small viewport.

For content designed to scroll horizontally, WCAG uses a height equivalent to 256 CSS pixels. In practice, zoom scales width and height together, so we test at a small width and a small height together when possible, then validate with zoom on real devices when issues show up.

What’s the Difference Between 1.4.4 Resize Text and 1.4.10 Reflow?

Both help users with visual impairments, but they solve different problems. One is about text size. The other is about layout under zoom.

WCAG 1.4.4 Resize Text focuses specifically on making text larger. It requires that users can zoom text up to 200% without needing assistive tools like screen magnifiers, and without the page layout breaking. If you need that extra boost in text size to read comfortably, this criterion keeps content readable and functional at that scale.

WCAG 1.4.10 Reflow, on the other hand, is about layout behavior. This criterion requires that content can be zoomed up to 400% without needing horizontal scrolling. It ensures everything—text, images, buttons—fits within the screen’s width,  especially when the effective viewport becomes narrow. The goal is to keep scrolling in one direction (usually up and down), so users aren’t stuck scrolling side to side to follow content.

In short, 1.4.4 scales text, while 1.4.10 makes sure the page layout adapts at high zoom without breaking use.

Why Horizontal Scrolling Hurts Users

When content does not reflow, reading turns into a repetitive pattern: scroll right to finish a line, then scroll left to find the start of the next. We’ve watched users lose their place after each line break because the viewport moved more than the text. The page still “worked,” but reading became the task.

Dr. Wayne Dick’s research on horizontal scrolling links it to increased reading effort and reduced comprehension. In testing, we see the same behavior. Time to complete a task climbs. Errors climb. People abandon the page sooner.

Reflow also reduces physical effort. Horizontal scrolling often requires more precise movement than vertical scrolling. Trackpads, touch gestures, and wheel setups all behave differently. Under magnification, the precision demands go up fast.

Who Gets Blocked When Reflow Fails

• Low vision: You zoom in to read. Your layout should stay readable without side-scrolling.
• Small screens (mobile or split-screen): You have limited width. Your content should reflow so that reading and controls stay in one direction.
• Keyboard or switch controls: You move focus step by step. The focus should remain visible, and controls should not slide off-screen at high zoom levels.
• Cognitive or attention-related disabilities: You follow structure and spacing. Your experience improves when content doesn’t shift sideways or break into hard-to-track fragments.

CSS Fixes That Help Content Reflow

Reflow issues often come from overflow. Fixes tend to work best when you address the cause, rather than hiding the symptom. The work almost always sits at the component level.

• Use Flexbox and Grid with restraint. Start by removing explicit widths. Let items grow and shrink. Add flex-wrap so rows can stack when space is tight. Media queries still matter, but they should not block zoom behavior.
• Keep media inside its container. Set images and video to max-width: 100% (and typically height: auto). Without this, one fixed-width asset can force horizontal scroll at high zoom.
• Let UI expand when text wraps. Test long labels, buttons, and badges. If a label wraps to two lines, the component should grow vertically. Avoid height constraints that clip text.
• Remove shrink blockers in flex layouts. If a flex child refuses to shrink and pushes the page wide, check for min-width (including defaults). Adjust or override when needed so the layout can reflow.
• Handle long strings at the right container. Apply wrapping rules where the overflow originates (not globally). Use options like overflow-wrap: anywhere; or word-break deliberately for URLs, IDs, and unbroken strings.
• Contain exempt content instead of the whole page. For tables, use a scrollable container with overflow: auto. Keep the table’s width intact inside that container. This respects the exception while protecting the rest of the page.
• For exempt sections, isolate scrolling to the section itself. Tables, code blocks, and specialized regions should scroll inside their own containers so the page does not inherit page-level horizontal scrolling.
• Sticky UI needs narrow-viewport rules. Switch fixed positioning to static positioning, collapse UI into a toggle pattern, or reduce footprint so content and focus remain visible.

Reflow Exceptions: Tables, Maps, and More

Some content needs a two-dimensional layout to keep its meaning or function. Data tables with multiple columns are the most common example. Maps, diagrams, video, games, presentations, and interfaces that require persistent toolbars can fall into this category, too.

The exception is limited. If a table qualifies for a two-dimensional layout, the exception applies to the table area. It does not grant permission for the rest of the page to overflow. We have reviewed pages where a wide table forced page-level horizontal scrolling, and then a paragraph below the table also extended off-screen. The table sits under the exception. The paragraph does not. That pattern fails 1.4.10 Reflow.

How to Test WCAG 1.4.10 Reflow

We use two passes. The steps stay the same. Recreate an equivalent small viewport, then try to use the page.

1. Test Reflow in Chrome DevTools

We start in Chrome DevTools and set a custom device size close to 320 by 256. WCAG lists width and height separately, but zoom scales both dimensions together, so testing them together catches common failures.

1. Open DevTools and toggle the device toolbar.
2. Add a custom device near 320×256 and load the page.
3. Look for loss of content, loss of function, overlap, clipping, and page-level two-direction scrolling.
4. Do a quick task run: read a paragraph, open main navigation, tab through a form, trigger an error state, then recover.

2. Validate With 400% Zoom on Real Devices

When we see issues, we confirm with browser zoom at 400% on one or two laptops. The usable viewport changes with browser chrome, OS scaling, scrollbars, and docked windows. We’ve seen pages look fine in an emulated viewport, then fail at 400% because sticky UI took most of the remaining height.

Find the Element Causing Horizontal Scroll

• Set zoom to 400% and get the viewport down to an equivalent narrow width by resizing the window or using responsive mode.
• Watch for page-level horizontal scroll. If it appears, inspect which element is pushing past the viewport. Often, one container causes the full issue.
• Read standard content. If a paragraph requires side-scrolling, that section fails 1.4.10 Reflow.
• Tab through navigation, forms, and core controls. If focus moves off-screen horizontally or ends up behind fixed UI, treat it as a failure pattern tied to reflow behavior.
• Check high-risk components. Tables, carousels, media embeds, code blocks, and long strings. Confirm that the exempt content is contained, and that the surrounding content still reflows.

When the Viewport Shows 318 Instead of 320

If you see 318 in DevTools at 400% zoom, that’s common. Scrollbars and browser chrome reduce available space. Focus on the requirement. Standard content reads and works without two-direction scrolling, at an equivalent small viewport.

Make Reflow Part of Your Release Checks

Start with your highest-traffic templates: article pages, account pages, and form flows. Test them at 400 percent zoom and an equivalent narrow viewport. Fix overflow at the component level, not by forcing page-wide scrolling.

Avoid fixed-width wrappers in core layout. Contain exempt content inside its own scroll region. Constrain media to its container width. Adjust sticky UI rules at narrow widths so content and focus remain visible. Test with real strings and real error states.

At 216digital, we treat 1.4.10 Reflow as part of front-end quality. If you want help validating complex UI patterns and fixing root overflow issues without destabilizing your design system, schedule a complimentary ADA Strategy Briefing.