1.4.10 Reflow: what it requires and how to test it

What 1.4.10 requires

Content must be presentable without loss of information or functionality, and without scrolling in two dimensions, at a width equivalent to 320 CSS pixels for vertically scrolling content (or a height of 256 CSS pixels for horizontally scrolling content). W3C notes that 320 CSS pixels equals a 1280 pixel-wide viewport at 400% zoom. This is a plain-language summary. The normative text, including every exception, is in the W3C Recommendation, with the W3C's explanation in Understanding 1.4.10 (opens in a new tab) [1][2].

Exceptions and scope:

• Content that needs two-dimensional layout can scroll both ways. W3C's examples include maps, diagrams, video, games, presentations, data tables (not individual cells), and interfaces where toolbars must stay in view while manipulating content.
• Nothing may be lost. Hiding content or functions at small widths without an alternative way to reach them fails, even if there's no horizontal scroll.

Why it matters

People with low vision zoom in, often to 200–400%. If the layout doesn't reflow, every line of text needs horizontal scrolling to read: across, back, down, across again. Content that overflows off-screen, sticky headers that take half the zoomed viewport, and controls that disappear at small widths make a site unusable at the zoom levels people actually need.

Common failures

Fixed-width container

/* Fails */
.page { width: 1200px; }

/* Better */
.page { max-width: 1200px; width: 100%; }

Content that can't wrap

Long URLs, code or unbroken strings push the layout wider than the viewport.

/* Fails */
.card { white-space: nowrap; }

/* Better */
.card { overflow-wrap: anywhere; }

Sticky header eats the viewport at zoom

At 400% the header and banner cover most of the screen.

/* Fails */
header { position: sticky; top: 0; height: 160px; }

/* Better */
@media (max-height: 480px) { header { position: static; } }

Functions hidden at small widths

A filter panel or action menu is hidden on narrow screens with no alternative.

/* Fails */
@media (max-width: 600px) { .filters { display: none; } }

/* Better */
@media (max-width: 600px) { .filters { display: none; } .filters-toggle { display: block; } }

Can automated testing check 1.4.10?

No. axe-core maps no rules to 1.4.10. Reflow depends on how the rendered layout behaves at a specific viewport, and on whether anything was lost, which needs a person.

What automation can't decide: Whether the page scrolls in two directions at 320 CSS pixels, whether content or functions disappear or overlap, and whether a section legitimately needs two-dimensional layout. (axe-core's meta-viewport rule, which flags pinch-zoom being disabled, maps to 1.4.4 Resize Text, not 1.4.10.)

A clean automated result is never proof that 1.4.10 is met. See why sites pass axe-core but fail real screen reader users.

How to test it by hand

1. Set a desktop browser window to 1280 CSS pixels wide and zoom to 400%, or use devtools responsive mode at 320 pixels wide.
2. Scroll through every page template. Is there horizontal scrolling for normal text content?
3. Check nothing is cut off, overlapping or missing: navigation, filters, form controls, buttons, dialogs.
4. Open menus, dialogs and tooltips at this size and confirm they fit and can be closed.
5. Exempt only content that truly needs two-dimensional layout (maps, data tables, diagrams), and check it scrolls within its own container.

New to screen readers? Start with how to test a website with a screen reader and how to test keyboard-only navigation.

How Accessible helps (and where it stops)

Accessible doesn't test reflow directly: scans have no 1.4.10 rule, and journeys don't resize the viewport. What real-user monitoring adds is context: viewport size, zoom level and root font size travel with each finding, so a barrier that only appears for zoomed-in visitors is attributable to those visitors (real-user monitoring).

Where it stops: Whether a page reflows at 320 CSS pixels is a manual test. It takes a few minutes per template, and nothing automated replaces it. No automated tool, ours included, can certify that a criterion is met.

Related criteria

• 2.5.8 Target Size (Minimum)
• 1.4.11 Non-text Contrast
• 1.3.1 Info and Relationships
• WCAG 2.2 success criteria checklist

Sources

1. Understanding Success Criterion 1.4.10: Reflow (opens in a new tab). W3C Web Accessibility Initiative. Accessed October 18, 2026.
2. Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 1.4.10 (opens in a new tab). W3C Recommendation. Accessed October 18, 2026.
3. axe-core rule descriptions (opens in a new tab). Deque Systems, axe-core 4.13.0. Accessed October 18, 2026.

Meeting a success criterion is not the same as legal compliance, which depends on the rules that apply to you. No automated tool can certify conformance.