WCAG 1.4.10 · Level AA · EN 301 549 9.1.4.10

Reflow

Requires content to adapt to a 320 CSS pixel width (400% zoom) without losing information or needing two-dimensional scrolling.

In brief

People with low vision often zoom a page to 400%. On a desktop browser that is the same as viewing the page at a width of 320 CSS pixels. If the layout does not adapt, they have to scroll sideways on every line, which makes reading very slow and tiring.

This criterion requires that content can be presented without loss of information or functionality, and without scrolling in two dimensions, at a width of 320 CSS pixels (for vertically scrolling content) or a height of 256 CSS pixels (for horizontally scrolling content). Content that needs two-dimensional layout to be usable is an exception.

What does it cover?

  • The test: At 400% zoom on a 1280 px wide window, or at 320 px width, the page reflows into one column. Nothing is cut off, hidden or overlapping, and there is no horizontal scrolling for reading.
  • Responsive design: Fluid layouts, flexible grids and media queries are the usual way to meet it.
  • Horizontal writing and vertical scrolling: The 320 px width applies. For content that scrolls horizontally, such as vertical writing systems, the 256 px height applies.
  • Exceptions: Parts of content that need two-dimensional layout for meaning or use: images, maps, diagrams, video, games, presentations, data tables and interfaces where toolbars must stay in view while working.
  • Long strings: URLs and long words should wrap instead of forcing a horizontal scrollbar.
  • Out of scope: Resizing text without assistive technology is 1.4.4, and text spacing is 1.4.12. Orientation is 1.3.4.

Who does it affect?

People with low vision who zoom to 400%. People who use a small screen or a narrow window. People with cognitive or reading differences who find a single column easier. People who use a magnifier or a large-text setting on a phone.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Content that adapts to the viewport is part of "perceivable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 1.4.10 by reference and turns it into separate clauses for each kind of ICT.

Where WCAG 1.4.10 appears in EN 301 549
ClauseType of ICTWhat it requires
9.1.4.10Web pagesWeb content must satisfy WCAG success criterion 1.4.10.
11.1.4.10Non-web software (native mobile apps)Software must reflow its content without two-dimensional scrolling, except where two-dimensional layout is essential.

Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 1.4.10 is the same in WCAG 2.1 and 2.2. It is a Level AA criterion.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. Allow the page to scale

A fixed viewport width or blocked zoom makes reflow impossible.

Incorrect
<meta name="viewport" content="width=1024">
Correct
<meta name="viewport" content="width=device-width, initial-scale=1">

2. Fluid widths instead of fixed widths

Fixed pixel widths force horizontal scrolling on a narrow viewport. Use max-width and relative units.

Incorrect
.container { width: 960px; }
Correct
.container { width: 100%; max-width: 60rem; margin-inline: auto; }

3. Grids that stack

Let columns wrap when there is no room, without a fixed number of columns.

Incorrect
.grid { display: grid; grid-template-columns: repeat(3, 300px); }
Correct
.grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 16rem), 1fr));
  gap: 1rem;
}

4. Wrap long text

Long URLs and words should wrap rather than push the page wider.

Incorrect
.comment { white-space: nowrap; }
Correct
.comment { overflow-wrap: anywhere; }

5. Images and media

Media should never be wider than its container.

Incorrect
img { width: 800px; }
Correct
img, video { max-width: 100%; height: auto; }

6. Data tables: the allowed exception

A data table may scroll sideways, but keep the scrolling inside the table so the rest of the page still reflows, and make the region reachable by keyboard.

Incorrect
<table>…</table> <!-- makes the whole page scroll sideways -->
Correct
<div class="table-scroll" role="region"
     aria-labelledby="t-cap" tabindex="0">
  <table>
    <caption id="t-cap">Quarterly results</caption>
    …
  </table>
</div>

.table-scroll { overflow-x: auto; }

Code examples for mobile

In native apps the same idea applies when the user enlarges text or uses a small window or split screen. Use flexible layouts that wrap and scroll vertically instead of fixed frames.

iOS (SwiftUI)

import SwiftUI

struct ProfileCard: View {
    var body: some View {
        // Avoid: fixed widths and a single horizontal row
        // HStack { Avatar().frame(width: 120); Details().frame(width: 400) }

        // ViewThatFits switches to a vertical layout when there is no room
        ViewThatFits(in: .horizontal) {
            HStack(alignment: .top, spacing: 16) {
                Avatar()
                Details()
            }
            VStack(alignment: .leading, spacing: 12) {
                Avatar()
                Details()
            }
        }
        .padding()
    }
}

Android (Jetpack Compose)

import androidx.compose.foundation.layout.*
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.unit.dp

@Composable
fun ProfileCard() {
    // Avoid: Row with fixed widths that cannot wrap
    // Row { Avatar(Modifier.width(120.dp)); Details(Modifier.width(400.dp)) }

    // FlowRow wraps its children onto the next line when there is no room
    FlowRow(
        modifier = Modifier.fillMaxWidth().padding(16.dp),
        horizontalArrangement = Arrangement.spacedBy(16.dp),
        verticalArrangement = Arrangement.spacedBy(12.dp)
    ) {
        Avatar()
        Details()
    }
}

How to test

  • Zoom to 400%: Set the browser window to 1280 px wide and zoom to 400%, or resize to 320 px. Do you have to scroll sideways to read? Is anything cut off or overlapping?
  • Use device mode: Set a 320 px width in the browser developer tools. Check every main template: home, forms, articles, tables and checkout.
  • Check all functions: Menus, dialogs, forms and buttons must still work at that width.
  • Look for the exceptions: Does the remaining horizontal scrolling come only from content that needs two-dimensional layout, such as a data table or a map?
  • Review the code: Look for fixed pixel widths, min-width values, white-space: nowrap and a restrictive viewport tag.
  • Check mobile: Use the largest text size and a split screen or a small device. Does the layout wrap and scroll only vertically?
  • Use a checker as a starting point: Automated tools can flag a blocked viewport but cannot judge whether content is lost. A person must look.

Common mistakes

  • Fixed-width layouts: A 960 px container breaks at 320 px.
  • Blocking zoom in the viewport: It prevents the 400% test altogether.
  • Hiding content on small screens: Removing a feature at narrow widths is a loss of functionality.
  • Whole-page horizontal scroll because of one wide element: An image, a long URL or a table pushes everything. Contain it.
  • Sticky bars that fill the screen: A fixed header can take up most of a 256 px high viewport.
  • Cut-off text: Fixed heights with hidden overflow lose text.
  • Testing only the home page: Forms and tables are usually the first to break.
  • Calling every wide element an exception: The exception covers content that really needs two dimensions, not ordinary text blocks.

Sources

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.

Corpowid is recognized by Gartner

Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.

Have questions about Corpowid?

Let’s connect.

We will get back to you as soon as possible.