WCAG 1.4.10: Reflow

What This Rule Means

WCAG 1.4.10 Reflow is a Level AA success criterion introduced in WCAG 2.1 and carried forward into WCAG 2.2. It specifies that web content must be able to reflow — that is, reorganize and resize itself — so that it remains fully usable at a viewport width equivalent to 320 CSS pixels, without requiring the user to scroll horizontally to read or interact with the content. The reference point of 320 CSS pixels corresponds to what a user sees when they set their browser zoom level to 400% on a standard 1280px-wide display.

The core requirement is that no loss of information or functionality occurs at this constrained width. All text must remain readable, all interactive controls must remain operable, and all meaningful content must remain visible without triggering two-dimensional scrolling. Vertical scrolling is permitted — the criterion only prohibits horizontal scrolling for vertically flowing content (and vertical scrolling for horizontally flowing content, though this is rare). A layout that forces users to scroll both up-and-down and left-and-right simultaneously to read a paragraph of text would fail this criterion.

The W3C defines explicit exceptions where two-dimensional scrolling is acceptable. These include content where two-dimensional layout is essential to its use and meaning: large data tables with many columns, complex maps and geographic diagrams, video players and their playback controls, toolbars with multiple action buttons laid out side by side, and games or interactive diagrams that require a precise spatial relationship between elements. These exceptions must be narrowly interpreted — the exemption applies to the content itself (for example, the cells of a data table), not to surrounding navigation, headings, or explanatory text that accompanies it.

A page passes this criterion if: when the browser is zoomed to 400% (or the viewport is set to 320px wide), content reflows into a single column, navigation collapses or stacks appropriately, images resize proportionally, and the user can accomplish everything they could at the default zoom level using only vertical scrolling. A page fails if horizontal scrolling is required to read sentences, reach buttons, or access any non-exempt content.

Why It Matters

Approximately 2.2 billion people worldwide live with some form of vision impairment, according to the World Health Organization. A significant proportion of those individuals rely on browser zoom, operating system magnification, or dedicated screen magnification software (such as ZoomText or Windows Magnifier) to make text and interface elements large enough to perceive comfortably. When a layout breaks at high zoom levels — forcing content off-screen or requiring horizontal scrolling — these users face a fragmented reading experience where every sentence requires a back-and-forth panning motion. This is not merely inconvenient; it can make complex content effectively inaccessible.

Consider a 65-year-old user with age-related macular degeneration who browses a Turkish hospital's appointment booking portal with their browser set to 300% zoom. If the booking form renders with fixed-width columns, the "Submit" button may be pushed entirely off the right edge of the visible area. The user has no way of knowing the button exists, let alone interacting with it. They cannot book their appointment independently. This is a direct, concrete harm caused by failing Reflow.

Beyond users with low vision, Reflow benefits a wide range of people. Users with motor impairments who use switch access or head-tracking devices find horizontal scrolling extremely difficult or impossible to perform reliably. Cognitive disability affects a significant portion of the population, and research consistently shows that narrow, single-column layouts — typical of well-implemented Reflow — reduce cognitive load and improve reading comprehension. People using small-screen devices or reading in split-screen mode also benefit directly, even without any disability.

From a technical and business perspective, implementing Reflow correctly overlaps almost entirely with building a well-structured responsive design. This means that conformance to 1.4.10 naturally improves mobile usability, reduces bounce rates, and contributes positively to Core Web Vitals metrics that influence search engine rankings. For Turkish e-commerce platforms in particular, where mobile traffic dominates, Reflow compliance and commercial mobile optimization are essentially the same goal.

Related Axe-core Rules

WCAG 1.4.10 Reflow requires manual testing rather than automated scanning. No axe-core rule can fully automate the detection of Reflow failures because the criterion depends on the visual and functional behavior of an entire rendered layout at a specific viewport size — something that requires a real browser environment, human judgment about scrollability, and verification that no information has been lost. Automated tools cannot reliably distinguish between intentional two-dimensional scrolling (for an exempt map or table) and an unintentional layout overflow caused by a fixed-width container.

• Manual test — 320px viewport width: Resize the browser viewport to exactly 320 CSS pixels wide (or zoom to 400% on a 1280px-wide screen) and scroll vertically through every page template, screen state, and interactive component. Verify that no content is clipped, no horizontal scrollbar appears for non-exempt content, and all functionality remains reachable. Axe DevTools will flag this as a "Needs Review" item rather than an automatic violation, because tool-based layout analysis cannot determine whether overflow represents a genuine failure or falls under an exemption.
• Automated partial signal — viewport meta tag check: Axe-core can detect whether the page uses a meta name='viewport' tag with user-scalable=no or maximum-scale=1, both of which prevent users from zooming at all and therefore make it impossible to reach the 400% zoom state that Reflow targets. While this is technically a separate issue (WCAG 1.4.4), it is closely related and its presence guarantees a Reflow failure. Axe flags this under the meta-viewport rule. Any page that blocks zoom also blocks Reflow compliance by definition.
• Manual component audit: Beyond full-page layout, individual components such as carousels, sticky headers, modal dialogs, floating chat widgets, cookie banners, and data tables each require individual verification at 320px. A page header may reflow correctly while a promotional modal renders with a fixed 600px width and an unreachable close button — a failure that only a manual component-by-component review will catch.

How to Test

1. Automated pre-scan: Run axe DevTools or Lighthouse in Chrome DevTools against each page. Look specifically for the meta-viewport violation, which indicates zoom is blocked and guarantees a Reflow failure. Also note any overflow-related warnings flagged under "Needs Review." Record results but understand that a clean automated scan does not confirm Reflow conformance — manual steps are mandatory.
2. Set viewport to 320px: In Chrome or Firefox DevTools, open the device toolbar (Ctrl+Shift+M / Cmd+Shift+M), enter a custom device size of 320×568 pixels (or any height), and set device pixel ratio to 1. Alternatively, open a 1280px-wide browser window and zoom to 400% using Ctrl+= (Cmd+= on Mac). Both methods simulate the 320 CSS pixel condition specified by WCAG.
3. Scroll vertically through the entire page: Starting from the top of the page, scroll downward only using the vertical scrollbar or mouse wheel. At no point should a horizontal scrollbar appear for non-exempt content. If one does, the page fails. Confirm that all text is fully readable — no sentences are cut off, no characters are clipped by the viewport edge.
4. Test all interactive functionality: While at 320px width, attempt to complete every key user task: fill in and submit forms, open navigation menus, activate modals and dialogs, use accordions and tabs, interact with carousels, and trigger any dynamic content. Every control must be reachable and operable using only vertical scrolling and normal interaction.
5. Check all page templates and states: Test the homepage, interior content pages, forms, checkout flows, error states, and any authenticated views. A responsive navigation that collapses correctly on the homepage may still break on a deeply nested product page with a different template.
6. Screen reader pairing (supplementary): Use NVDA with Firefox or VoiceOver with Safari at 320px width to confirm that content order and meaning are preserved after reflow. Sometimes CSS-based reflow changes visual order without altering DOM order, causing screen reader announcements to become confusing. This is not strictly a Reflow test, but it catches reflow implementations that create separate accessibility problems.
7. Document exemptions: For any content that does require horizontal scrolling (data tables, maps, code blocks), verify and document that it genuinely falls under a WCAG-defined exception. Confirm that the surrounding page content (headings, instructions, navigation) still reflows correctly even if the embedded component does not.

How to Fix

Fixed-width container breaking layout — Incorrect

<!-- Fixed pixel width forces horizontal scrolling at small viewports -->
<div style='width: 960px; margin: 0 auto;'>
  <p>This content will overflow a 320px viewport and require horizontal scrolling.</p>
  <button>Submit Application</button>
</div>

Fixed-width container breaking layout — Correct

<!-- Use max-width with 100% so container never exceeds its parent but shrinks on small screens -->
<div class='content-wrapper'>
  <p>This content reflows naturally at any viewport width.</p>
  <button>Submit Application</button>
</div>

<!-- In your CSS (external stylesheet) -->
<!-- .content-wrapper { max-width: 960px; width: 100%; margin: 0 auto; box-sizing: border-box; padding: 0 1rem; } -->

Viewport meta tag blocking zoom — Incorrect

<!-- This prevents users from zooming at all, making Reflow impossible to achieve -->
<meta name='viewport' content='width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no'>

Viewport meta tag blocking zoom — Correct

<!-- Allow zooming by removing maximum-scale and user-scalable restrictions -->
<meta name='viewport' content='width=device-width, initial-scale=1'>
<!-- Users can now zoom to 400% and content will reflow as required by WCAG 1.4.10 -->

Horizontal navigation bar overflowing — Incorrect

<!-- Navigation items forced into a single row with no wrapping or collapse mechanism -->
<nav aria-label='Primary navigation'>
  <ul style='display: flex; flex-wrap: nowrap; white-space: nowrap;'>
    <li><a href='/home'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About Us</a></li>
    <li><a href='/contact'>Contact</a></li>
    <li><a href='/blog'>Blog</a></li>
    <li><a href='/support'>Support</a></li>
  </ul>
</nav>

Horizontal navigation bar overflowing — Correct

<!-- Hamburger/disclosure pattern for small viewports; full navigation accessible at all sizes -->
<nav aria-label='Primary navigation'>
  <button aria-expanded='false' aria-controls='nav-menu' id='nav-toggle'>
    Menu
  </button>
  <ul id='nav-menu'>
    <li><a href='/home'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About Us</a></li>
    <li><a href='/contact'>Contact</a></li>
    <li><a href='/blog'>Blog</a></li>
    <li><a href='/support'>Support</a></li>
  </ul>
</nav>
<!-- CSS media query hides #nav-menu by default below a breakpoint and shows it on toggle -->
<!-- The button is hidden above the breakpoint where the full nav is always visible -->

Data table without reflow accommodation — Incorrect

<!-- Wide table with no scroll container; overflows the viewport with no warning to users -->
<table>
  <caption>Quarterly Sales Data</caption>
  <thead>
    <tr>
      <th scope='col'>Region</th>
      <th scope='col'>Q1</th>
      <th scope='col'>Q2</th>
      <th scope='col'>Q3</th>
      <th scope='col'>Q4</th>
      <th scope='col'>Total</th>
    </tr>
  </thead>
</table>

Data table without reflow accommodation — Correct

<!-- Wrap the table in a scrollable container scoped to just the table element -->
<!-- This is an explicit WCAG 1.4.10 exception for complex data tables -->
<div role='region' aria-labelledby='table-caption' tabindex='0' class='table-scroll-container'>
  <table>
    <caption id='table-caption'>Quarterly Sales Data (scroll horizontally to view all columns)</caption>
    <thead>
      <tr>
        <th scope='col'>Region</th>
        <th scope='col'>Q1</th>
        <th scope='col'>Q2</th>
        <th scope='col'>Q3</th>
        <th scope='col'>Q4</th>
        <th scope='col'>Total</th>
      </tr>
    </thead>
  </table>
</div>
<!-- CSS: .table-scroll-container { overflow-x: auto; } -->
<!-- The caption warns users, role=region + aria-labelledby makes it keyboard-focusable -->

Common Mistakes

• Using overflow: hidden on the <body> or a top-level wrapper to suppress horizontal scrollbars without fixing the underlying overflow: This hides the scrollbar but the content is still clipped and inaccessible, which is arguably worse than visible overflow because the user has no indication that content exists beyond the viewport edge.
• Setting max-scale=1 or user-scalable=no in the viewport meta tag to prevent a mobile layout from "looking broken" at high zoom: This disables the user's ability to zoom entirely, which is both a Reflow failure and a violation of WCAG 1.4.4 Resize Text.
• Applying white-space: nowrap to text containers, navigation lists, or button groups without a breakpoint-specific override: This forces text onto a single line regardless of available space and is one of the most common causes of horizontal overflow at 320px.
• Using absolute pixel values in CSS Grid grid-template-columns definitions (e.g., grid-template-columns: 300px 600px) without a responsive fallback: At 320px the two columns total 900px and will overflow with no reflow unless a media query replaces the definition with 1fr or 100%.
• Embedding <iframe> elements with fixed width and height attributes pointing to third-party content (maps, videos, forms): Iframes do not automatically scale, so a 600px-wide embedded map will overflow a 320px viewport. Wrap iframes in an aspect-ratio-preserving container and set the iframe itself to width: 100%.
• Designing modal dialogs and off-canvas panels with a fixed minimum width larger than 320px: A modal with min-width: 500px will overflow and likely hide its close button off-screen, trapping keyboard users inside the dialog at small viewport widths.
• Treating code blocks and <pre> elements as exempt from Reflow without wrapping them in a horizontally scrollable container: Raw code blocks are not listed as a WCAG exception. While the code content itself may be complex, the surrounding page must reflow; the code block should scroll independently within a overflow-x: auto wrapper, not cause the whole page to scroll horizontally.
• Forgetting to test authenticated and dynamic states: Many teams test only the logged-out homepage. Dashboards, user profile pages, multi-step forms, and error states loaded via JavaScript are frequently built with fixed-width assumptions and fail Reflow even when marketing pages pass.
• Using CSS transform: scale() to visually shrink content rather than implementing true responsive layout: Scaling reduces the apparent size but does not reflow content — text becomes tiny and unreadable rather than reflowing into a readable single column, which fails both Reflow and Resize Text criteria.
• Assuming that a mobile-responsive design automatically passes Reflow: Responsive design typically targets breakpoints at 360px, 768px, and 1024px. The WCAG reference point of 320px is narrower than most mobile breakpoints, meaning content that looks correct on a standard small phone may still overflow at 320px. Always test at exactly 320px, not at a generic "mobile" size.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette numbered 32933 on June 21, 2025, establishes binding accessibility requirements for a wide range of digital service providers operating in Turkey. The circular mandates conformance with international web accessibility standards — with WCAG 2.1 Level AA serving as the baseline — for covered entities. WCAG 2.2 Level AA, which incorporates all 2.1 criteria including 1.4.10 Reflow, is strongly encouraged and is the standard required for obtaining the Erişilebilirlik Logosu (Accessibility Logo) issued by the Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı).

The covered entity types under Presidential Circular 2025/10 include public institutions and government bodies at all levels, banks and financial institutions, hospitals and healthcare providers, telecommunications companies with 200,000 or more subscribers, e-commerce platforms, travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (Millî Eğitim Bakanlığı). For each of these sectors, the expectation is that all public-facing digital interfaces — websites, web applications, and mobile web content — must be accessible to people with disabilities, including those who rely on zoom and viewport adjustment to perceive content.

WCAG 1.4.10 Reflow is particularly relevant in the Turkish context for several reasons. First, mobile internet penetration in Turkey is exceptionally high, and a substantial portion of users access government services, banking portals, and e-commerce platforms via mobile browsers at varying zoom levels. A hospital appointment system that fails Reflow may prevent elderly patients with low vision from independently booking consultations — a direct failure of both accessibility law and the public service mission of covered institutions. Second, the Erişilebilirlik Logosu program requires a conformance audit covering all Level AA success criteria; failing 1.4.10 would disqualify an otherwise compliant site from receiving the logo. Third, for telecommunications companies with large subscriber bases, accessible self-service portals and account management interfaces are essential — a fixed-width account dashboard that overflows at 400% zoom directly harms subscribers with visual impairments who would otherwise not need to visit a physical store or call a support line.

Organizations seeking to demonstrate conformance under Turkish accessibility regulations should ensure that their responsive design implementations are specifically validated at the 320 CSS pixel threshold, that no viewport meta tags block user zoom, and that all interactive functionality — including authentication flows, form submissions, and document downloads — remains fully operable without horizontal scrolling. Including Reflow testing as part of a documented accessibility audit trail will be essential for demonstrating compliance to regulatory bodies and for maintaining eligibility for the Erişilebilirlik Logosu.