For each web page, can content be presented without loss of information or functionality and without requiring either vertical scrolling for a window with a height of 256px, or horizontal scrolling for a window with a width of 320px (except in special cases)?
A visually impaired visitor zooms their browser to 400% on a 1280 px screen. Their effective window shrinks to 320 px wide. If your page forces horizontal scrolling, they must manage two axes simultaneously: move forward through reading and reposition sideways after each line. This is exhausting, if not impossible.
Criterion 10.11 sets a clear rule: at 320 px wide (for horizontally-read content) or 256 px tall (for vertically-read content), all content and functionality remain accessible without scrolling in the secondary axis. No horizontal scroll when reading left to right. This is the application of WCAG criterion 1.4.10 "Reflow".
In practice, max-width: 100% on images, flex-wrap: wrap on navigation bars, and width values expressed in % or em rather than fixed pixels allow content to redistribute naturally. This is not a constraint: it is responsive design done well.
The 320 px is not a smartphone size. It is the viewport of a desktop browser displayed at 400% zoom. Keep this scenario in mind from the design phase onward.
2 tests to verify content adaptation to small windows
Horizontal reflow at 320 px
This test applies to pages with horizontal reading (French, English, etc.).
- Reduce the browser window to 320 px wide (using developer tools in responsive mode, or by setting zoom to 400% on a 1280 px screen).
- Scroll the page from top to bottom.
- Verify that no horizontal scrolling is necessary to access all information and functionality.
If any content or functionality requires horizontal scroll to be reached, the test fails.
Vertical reflow at 256 px
This test applies to pages with vertical reading (certain CJK languages such as Japanese in tategaki mode).
- Reduce the browser window to 256 px tall.
- Scroll the page from left to right.
- Verify that no vertical scrolling is necessary to access all information and functionality.
If any content requires vertical scroll to be read or used, the test fails. For the vast majority of web projects in French, only test 10.11.1 applies.
Examples
❌ Non-compliant : Navigation bar blocked by white-space: nowrap
<nav>
<ul style="display: flex; white-space: nowrap; gap: 16px; list-style: none; padding: 0;">
<li><a href="/home">Home</a></li>
<li><a href="/services">Our services</a></li>
<li><a href="/portfolio">Portfolio</a></li>
<li><a href="/blog">Blog</a></li>
<li><a href="/contact">Contact us</a></li>
</ul>
</nav>The white-space: nowrap property prevents links from repositioning across multiple lines. At 320 px, the last items overflow the viewport and force the user to scroll horizontally. A visitor zooming to 400% on a desktop cannot reach the last menu links without horizontal scroll.
✅ Compliant : Responsive navigation bar with flex-wrap
<nav>
<ul style="display: flex; flex-wrap: wrap; gap: 8px; list-style: none; padding: 0; margin: 0;">
<li><a href="/home">Home</a></li>
<li><a href="/services">Our services</a></li>
<li><a href="/portfolio">Portfolio</a></li>
<li><a href="/blog">Blog</a></li>
<li><a href="/contact">Contact us</a></li>
</ul>
</nav>flex-wrap: wrap allows items to wrap to the next line as soon as space runs out. At 320 px, links redistribute across multiple lines without causing horizontal scrolling. All navigation functionality remains accessible.
❌ Non-compliant : Image with fixed width in pixels
<figure>
<img src="schema-processus.png" alt="Process schema in 5 steps" style="width: 900px;">
<figcaption>Validation process in 5 steps</figcaption>
</figure>An image forced to 900 px overflows the viewport at 320 px and generates horizontal scrolling across the entire page, including surrounding text. Unless the image is a diagram whose understanding requires two dimensions simultaneously, it must adapt to available width.
✅ Compliant : Responsive image with max-width
<figure>
<img src="schema-processus.png" alt="Process schema in 5 steps" style="max-width: 100%; height: auto; display: block;">
<figcaption>Validation process in 5 steps</figcaption>
</figure>max-width: 100% combined with height: auto ensures the image never overflows its container, regardless of viewport width. At 320 px, it resizes proportionally and remains fully visible without horizontal scroll.
Tips and pitfalls
⚠️ overflow-x: hidden on body: the false remedy
Hiding horizontal scrolling via overflow-x: hidden is the most common mistake in audits. The content that was overflowing is still present in the DOM, but the user can no longer access it at all. We go from uncomfortable scrolling to total loss of information. Criterion 10.11 is violated in both cases.
⚠️ Certain content is explicitly exempt from reflow
Content that requires two dimensions to be understood or manipulated escapes the criterion: images and graphics, videos, data tables, presentation-type slideshows, games (platform games, for example) and interfaces where horizontal scrolling is functionally necessary. A financial table with 15 columns does not have to fit in 320 px. Running text, however, must redistribute.
💡 Test with both methods, not just one
Zooming to 400% and manually resizing to 320 px do not always produce the same result. Some CSS media queries are triggered by the actual browser window size but not by zoom. Do both tests: the results can diverge and reveal distinct problems.
⚠️ Mobile browsers: criterion non-applicable during zoom
The majority of browsers on Android and iOS do not properly handle content redistribution during zoom. Criterion 10.11 is therefore considered non-applicable in these specific environments. The audit focuses on desktop browsers where behavior is predictable and standardized.
⚠️ Elements in position: absolute or position: fixed that overflow
An element positioned absolute with fixed pixel coordinates can exceed the viewport at 320 px without developer tools flagging it immediately. Modals, tooltips, dropdown menus: check them all manually. These elements often escape automated tests and responsive media queries.
Frequently asked questions
How do I test RGAA criterion 10.11 reflow without a specific tool?
Two methods suffice. First method: open your browser's developer tools, enable responsive mode and set width to 320 px. Second method: set your browser's zoom to 400% on a 1280 px screen. In both cases, scroll the page vertically and verify that no horizontal scroll appears. Always do both: the results can diverge based on CSS media query behavior.
What RGAA reflow exceptions apply to a data table with many columns?
None. Data tables are part of the official exceptions to criterion 10.11. A table whose understanding requires seeing multiple columns simultaneously may legitimately impose horizontal scrolling. The exemption applies to the table itself, but the rest of the page (running text, navigation, forms) must still respect reflow.
What is the difference between test 10.11.1 and test 10.11.2?
Test 10.11.1 applies to pages with horizontal reading (French, English): we verify the absence of horizontal scroll at 320 px wide. Test 10.11.2 concerns pages with vertical reading (certain CJK languages such as Japanese in tategaki mode): we verify the absence of vertical scroll at 256 px tall. For nearly all web projects in French, only test 10.11.1 applies.
What impact does overflow-x: hidden on body have for fixing an RGAA reflow problem?
None, and it makes things worse. Hiding the scroll does not remove the content that overflows: it remains in the DOM but becomes inaccessible to the user. Criterion 10.11 requires that information and functionality remain available. Inaccessible content constitutes a loss of information and fails the criterion just as much as horizontal scroll.
How do I assess RGAA reflow responsibility for a third-party component that overflows at 320 px?
Yes. The RGAA audit evaluates the page as presented to the user, regardless of component origin. If a widget or carousel generates horizontal scrolling, the page fails criterion 10.11. Adapt the component by applying max-width: 100% to its container, or replace it with a compliant alternative.