1.4.10 Reflow
- Level AA
- Perceivable
- Since WCAG 2.1
Summary
People with low vision routinely browse at 200 to 400% zoom. If a page does not reflow, zooming turns every line of text into a horizontal scrolling exercise: read a few words, scroll right, scroll all the way back for the next line. This criterion requires content to present in a single scrolling direction at a width equivalent to 320 CSS pixels, which is exactly what a 1280 pixel wide viewport becomes at 400% zoom. Content that scrolls horizontally (vertically written languages, for instance) gets the mirrored requirement: a 256 CSS pixel height.
The requirement arrived in WCAG 2.1 at Level AA and is, in effect, a mandate for responsive layout. Nothing may be lost along the way: information and functionality available at full width must still be reachable at 320 pixels. The single exception covers content that genuinely requires two-dimensional layout for usage or meaning, such as data tables, maps, and diagrams; most audit disputes turn on whether it really applies.
Official wording
Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
Vertical scrolling content at a width equivalent to 320 CSS pixels;
Horizontal scrolling content at a height equivalent to 256 CSS pixels.
Except for parts of the content which require two-dimensional layout for usage or meaning.
EN 301 549 mapping
- Web pages
- Clause 9.1.4.10
- Software and native apps
- Clause 11.1.4.10 (via Table 11.2)
Clause 9.1.4.10 applies this criterion to web pages unchanged. For software, clause 11.1.4.10 carries an adapted version (Table 11.2) that adds an explicit height equivalent for horizontally scrolling content (256 CSS pixels) alongside the 320 pixel width, with software-specific notes replacing the WCAG ones.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Set the browser window to 1280 CSS pixels wide and zoom to 400%, or use the browser's responsive design mode at a 320 pixel width; the two are equivalent for this test. Then read the page top to bottom looking for three things: a horizontal scrollbar on the page itself, content clipped off the edge of the viewport, and text or controls overlapping one another. A well-built responsive layout simply becomes the mobile view; a fixed-width layout announces itself immediately.
Some content legitimately needs two dimensions: data tables, maps, complex diagrams, and code blocks where line breaks would change meaning. The exception covers these parts of the content, not the page around them. The correct pattern is a scrollable container: the table scrolls sideways within its own box while the surrounding prose reflows normally. If an oversized table forces the entire page to scroll horizontally, the prose around it fails even though the table itself is exempt.
Watch for loss of functionality, which is the subtler failure mode. Fixed-width text inputs whose contents are cut off, dialogs wider than the viewport with unreachable buttons, and features a responsive breakpoint quietly removes at mobile widths all fail. A "desktop only" filter panel that simply disappears at 320 pixels is a loss of functionality, not a design choice, unless the same capability remains available another way at that width.
iOS
There is no browser zoom in a native app, so reflow translates to how the layout responds when text gets much larger. The practical test is Dynamic Type at the largest accessibility sizes: turn the text size slider up to AX5 via Settings (or the text-size slider in Accessibility Inspector, which changes it live) and walk every screen. The question is the same as on the web: does the layout adapt, or does content get cut off?
The native equivalents of a horizontal scrollbar are truncation and clipping. A label that collapses to an ellipsis and hides meaning ("Cancel subscr..."), a fixed-height container that clips the enlarged text inside it, and a button whose title escapes its bounds are all reflow failures in spirit. Side-by-side arrangements are the other hotspot: a label and value that share one line at default sizes should stack vertically at accessibility sizes rather than squeezing each other into unreadable slivers.
Layouts built to adapt handle this well: SwiftUI views that let text wrap and containers grow reflow naturally, and layout code can switch from horizontal to vertical arrangements when an accessibility text size is active. Fixed frames, hard-coded heights, and single-line labels set to truncate are where the failures live.
Android
Android exposes two relevant user settings: font scale, which modern versions allow up to 200%, and display size, which enlarges the whole interface. Test with both pushed to maximum, most quickly through the developer options font scale control or the accessibility settings. As on iOS, the failure modes are clipped text, overlapping views, ellipsised labels that hide meaning, and controls pushed off screen with no way to scroll to them.
Layouts must be built to wrap and stack. Constraint-based and Compose layouts that size themselves from their content adapt cleanly; fixed heights on text containers, single-line text set to ellipsise, and rows of views with no room to grow are the usual culprits. Text sized in sp scales with the font setting while a container fixed in dp does not, and that mismatch is the most common cause of clipped text at maximum font scale.
Android adds one reflow scenario the other platforms lack: window resizing. Split-screen mode and small freeform windows hand the app a narrow viewport at runtime, much like the web's 320 pixel test. An app that locks itself to a full-screen layout and clips or overlaps in split-screen has the same problem as a fixed-width website.
Pass and fail examples
Passes:
- A marketing page whose three-column layout stacks into a single column at 320 CSS pixels with all content and controls intact.
- A data table that scrolls horizontally inside its own container while the page around it reflows: the two-dimensional exception applies to the table, and the page keeps one-directional scrolling.
- A settings screen where every label wraps onto extra lines at the largest accessibility text size and the rows grow to fit.
- A form whose side-by-side name fields stack vertically at 400% zoom.
Fails:
- A page with a fixed 960 pixel wrapper: at 400% zoom every paragraph requires horizontal scrolling to read.
- A "compare plans" feature that is simply absent below a desktop breakpoint, with no equivalent at mobile width: loss of functionality.
- A native app button whose label truncates to "Del..." at large text sizes, leaving Delete and Delivery indistinguishable.
- A fixed-height card that clips the second line of its enlarged text at maximum font scale.
- A cookie banner wider than the 320 pixel viewport whose accept button sits off screen and cannot be scrolled into view.
Not a fail under this criterion:
- A map that requires two-dimensional panning: geographic layout is meaningful in two dimensions, so the exception applies.
- A code block scrolling sideways within its own container: preserving line structure is a usage requirement, and the page itself still reflows.
- Body text that reflows correctly but has not grown to 200% of its original size: how large the text gets is a different question (see below); this criterion judges the layout.
Commonly confused with
- Resize Text, SC 1.4.4. The neighbouring criterion requires text to scale to 200% without loss; this one requires the layout to reflow when it does. A page can pass 1.4.4 with horizontal scrolling everywhere and still fail here: reflow is about the layout at zoom, 1.4.4 about the text itself reaching 200%.
- Target Size (Minimum), SC 2.5.8. When a layout squeezes at narrow widths, controls sometimes shrink or crowd together. The reflow finding is the layout breaking; controls that end up too small or too close are a separate target size finding on the same screen.
- Content hidden at mobile width. Responsive design may reorganise, collapse, and move content behind menus; it may not remove capability. The dividing line is functionality: reachable through a hamburger menu passes, gone entirely fails, and it fails here, under loss of functionality, rather than under some separate "mobile parity" rule.
- Text Spacing, SC 1.4.12. Also from WCAG 2.1 and often tested in the same pass, 1.4.12 overrides spacing properties (line height, letter spacing) and checks nothing clips. Both punish fixed-height containers, but the trigger differs: spacing overrides there, zoom and large text here.
How AUDITSU tests this
AUDITSU's audit walkthrough includes a reflow pass for every screen you review: on web, the 320 pixel or 400% zoom check; in native apps, the largest text size walk-through. The walkthrough prompts you to look for horizontal page scrolling, clipped or truncated content, overlaps, and anything that vanished compared with the full-width view, then asks whether any two-dimensional content is genuinely exempt and scrolls within its own container. Each check records a pass, fail, or not applicable result per screen with the evidence attached, so the finding lands in your report tied to the exact screen.
EN 301 549 carries this criterion for both websites and native software: the web requirement is WCAG's text unchanged, and the software requirement is an adapted version of the same wording with software-specific notes. AUDITSU applies the appropriate variant based on what you are auditing, so European Accessibility Act audits cover reflow across both.
For the full guided workflow, see the audit platform.