WCAG 1.4.10: Umfluss

WCAG 1.4.10 Reflow verlangt, dass Inhalte ohne Informations- oder Funktionsverlust und ohne zweidimensionales Scrollen dargestellt werden können, wenn sie mit einer Breite von 320 CSS-Pixeln angezeigt werden. Dies stellt sicher, dass Nutzer, die auf Zoom oder kleine Viewports angewiesen sind – einschließlich Menschen mit Sehbehinderungen und mobilen Nutzern – auf alle Inhalte zugreifen können, ohne horizontal scrollen zu müssen.

Was diese Regel bedeutet

WCAG 1.4.10 Reflow ist ein Erfolgskriterium der Stufe AA, das in WCAG 2.1 eingeführt und in WCAG 2.2 fortgeführt wurde. Es legt fest, dass Webinhalte in der Lage sein müssen, sich neu zu fließen – das heißt, sich neu zu organisieren und in der Größe anzupassen –, sodass sie bei einer Viewport-Breite, die 320 CSS-Pixeln entspricht, vollständig nutzbar bleiben, ohne dass der Nutzer horizontal scrollen muss, um den Inhalt zu lesen oder mit ihm zu interagieren. Der Referenzpunkt von 320 CSS-Pixeln entspricht dem, was ein Nutzer sieht, wenn er den Browser-Zoom auf 400% auf einem Standard-Display mit 1280px Breite einstellt.

Die Kernanforderung ist, dass bei dieser eingeschränkten Breite kein Informations- oder Funktionsverlust auftreten darf. Sämtlicher Text muss lesbar bleiben, alle interaktiven Steuerelemente müssen bedienbar bleiben, und alle bedeutungsvollen Inhalte müssen sichtbar bleiben, ohne dass ein zweidimensionales Scrollen ausgelöst wird. Vertikales Scrollen ist erlaubt – das Kriterium verbietet lediglich das horizontale Scrollen für vertikal fließende Inhalte (und vertikales Scrollen für horizontal fließende Inhalte, was jedoch selten ist). Ein Layout, das Nutzer zwingt, gleichzeitig nach oben/unten und nach links/rechts zu scrollen, um einen Textabsatz zu lesen, würde dieses Kriterium nicht erfüllen.

Das W3C definiert explizite Ausnahmen, bei denen zweidimensionales Scrollen akzeptabel ist. Dazu gehören Inhalte, bei denen ein zweidimensionales Layout für Nutzung und Bedeutung wesentlich ist: große Datentabellen mit vielen Spalten, komplexe Karten und geografische Diagramme, Videoplayer und ihre Wiedergabesteuerungen, Symbolleisten mit mehreren nebeneinander angeordneten Aktionsschaltflächen sowie Spiele oder interaktive Diagramme, die eine präzise räumliche Beziehung zwischen Elementen erfordern. Diese Ausnahmen sind eng auszulegen – die Ausnahme gilt für den Inhalt selbst (zum Beispiel die Zellen einer Datentabelle), nicht für die umgebende Navigation, Überschriften oder erklärende Texte, die ihn begleiten.

Eine Seite besteht dieses Kriterium, wenn: bei auf 400% gezoomtem Browser (oder auf 320px Breite eingestelltem Viewport) der Inhalt in eine einspaltige Darstellung übergeht, die Navigation sich passend zusammenklappt oder stapelt, Bilder proportional skaliert werden und der Nutzer alles, was er auch bei der Standard-Zoomstufe tun konnte, ausschließlich mit vertikalem Scrollen erledigen kann. Eine Seite fällt durch, wenn horizontales Scrollen erforderlich ist, um Sätze zu lesen, Schaltflächen zu erreichen oder auf nicht ausgenommene Inhalte zuzugreifen.

Warum das wichtig ist

Laut Weltgesundheitsorganisation leben weltweit etwa 2,2 Milliarden Menschen mit einer Form von Sehbeeinträchtigung. Ein erheblicher Teil dieser Personen ist auf Browser-Zoom, Betriebssystem-Vergrößerung oder spezielle Bildschirmvergrößerungssoftware (wie ZoomText oder Windows-Magnifier) angewiesen, um Text und Bedienelemente groß genug wahrnehmen zu können. Wenn ein Layout bei hohen Zoomstufen „auseinanderbricht“ – Inhalte aus dem sichtbaren Bereich drängt oder horizontales Scrollen erzwingt –, erleben diese Nutzer ein fragmentiertes Leseerlebnis, bei dem jeder Satz eine Hin-und-her-Schwenkbewegung erfordert. Das ist nicht nur unbequem; es kann komplexe Inhalte faktisch unzugänglich machen.

Stellen Sie sich eine 65-jährige Nutzerin mit altersbedingter Makuladegeneration vor, die das Terminbuchungsportal eines türkischen Krankenhauses mit auf 300% eingestelltem Browser-Zoom nutzt. Wenn das Buchungsformular mit Spalten fester Breite gerendert wird, kann die Schaltfläche „Absenden“ vollständig über den rechten Rand des sichtbaren Bereichs hinausgeschoben werden. Die Nutzerin hat keine Möglichkeit zu wissen, dass die Schaltfläche existiert, geschweige denn mit ihr zu interagieren. Sie kann ihren Termin nicht eigenständig buchen. Dies ist ein direkter, konkreter Schaden, der durch das Nichtbestehen von Reflow verursacht wird.

Über Nutzer mit Sehbeeinträchtigung hinaus kommt Reflow einer breiten Personengruppe zugute. Nutzer mit motorischen Beeinträchtigungen, die Schaltersteuerung oder Kopfsteuerungsgeräte verwenden, finden horizontales Scrollen äußerst schwierig oder unmöglich zuverlässig auszuführen. Kognitive Beeinträchtigungen betreffen einen erheblichen Teil der Bevölkerung, und Forschungsergebnisse zeigen konsistent, dass schmale, einspaltige Layouts – typisch für gut umgesetztes Reflow – die kognitive Belastung reduzieren und das Leseverständnis verbessern. Menschen, die Geräte mit kleinem Bildschirm verwenden oder im Split-Screen-Modus lesen, profitieren ebenfalls direkt, auch ohne Behinderung.

Aus technischer und geschäftlicher Perspektive überschneidet sich eine korrekte Reflow-Implementierung nahezu vollständig mit dem Aufbau eines gut strukturierten responsiven Designs. Das bedeutet, dass die Konformität mit 1.4.10 die mobile Nutzbarkeit natürlicherweise verbessert, Absprungraten reduziert und positiv zu Core-Web-Vitals-Metriken beiträgt, die das Ranking in Suchmaschinen beeinflussen. Insbesondere für türkische E-Commerce-Plattformen, bei denen der mobile Traffic dominiert, sind Reflow-Konformität und kommerzielle mobile Optimierung im Wesentlichen dasselbe Ziel.

Wie man testet

Automatischer Vorab-Scan: Führen Sie axe DevTools oder Lighthouse in den Chrome DevTools für jede Seite aus. Achten Sie speziell auf den Verstoß meta-viewport, der darauf hinweist, dass Zoom blockiert ist und einen Reflow-Fehler garantiert. Notieren Sie außerdem alle Überlauf-bezogenen Warnungen, die unter „Needs Review“ gekennzeichnet sind. Halten Sie die Ergebnisse fest, verstehen Sie aber, dass ein sauberer automatisierter Scan die Reflow-Konformität nicht bestätigt – manuelle Schritte sind zwingend erforderlich.
Viewport auf 320px einstellen: Öffnen Sie in den DevTools von Chrome oder Firefox die Gerätetoolleiste (Strg+Umschalt+M / Cmd+Umschalt+M), geben Sie eine benutzerdefinierte Gerätegröße von 320×568 Pixel (oder beliebige Höhe) ein und setzen Sie das Device Pixel Ratio auf 1. Alternativ können Sie ein 1280px breites Browserfenster öffnen und mit Strg+= (Cmd+= auf dem Mac) auf 400% zoomen. Beide Methoden simulieren die von WCAG spezifizierte Bedingung von 320 CSS-Pixeln.
Vertikal durch die gesamte Seite scrollen: Scrollen Sie, beginnend am oberen Seitenrand, ausschließlich mit dem vertikalen Scrollbalken oder dem Mausrad nach unten. Zu keinem Zeitpunkt sollte für nicht ausgenommene Inhalte ein horizontaler Scrollbalken erscheinen. Wenn doch, fällt die Seite durch. Bestätigen Sie, dass aller Text vollständig lesbar ist – keine Sätze werden abgeschnitten, keine Zeichen werden vom Viewportrand abgeschnitten.
Alle interaktiven Funktionen testen: Versuchen Sie bei 320px Breite, jede zentrale Nutzeraufgabe zu erledigen: Formulare ausfüllen und absenden, Navigationsmenüs öffnen, Modale und Dialoge aktivieren, Akkordeons und Tabs verwenden, mit Karussells interagieren und dynamische Inhalte auslösen. Jedes Steuerelement muss ausschließlich mit vertikalem Scrollen und normaler Interaktion erreichbar und bedienbar sein.
Alle Seitentemplates und Zustände prüfen: Testen Sie die Startseite, innere Inhaltsseiten, Formulare, Checkout-Flows, Fehlermeldungen und alle authentifizierten Ansichten. Eine responsive Navigation, die auf der Startseite korrekt zusammenklappt, kann auf einer tief verschachtelten Produktseite mit einem anderen Template dennoch brechen.
Screenreader-Kombination (ergänzend): Verwenden Sie NVDA mit Firefox oder VoiceOver mit Safari bei 320px Breite, um zu bestätigen, dass Reihenfolge und Bedeutung der Inhalte nach dem Reflow erhalten bleiben. Manchmal ändert CSS-basiertes Reflow die visuelle Reihenfolge, ohne die DOM-Reihenfolge zu verändern, was Screenreader-Ausgaben verwirrend machen kann. Dies ist nicht strikt ein Reflow-Test, deckt aber Reflow-Implementierungen auf, die separate Barrierefreiheitsprobleme erzeugen.
Ausnahmen dokumentieren: Für alle Inhalte, die horizontales Scrollen erfordern (Datentabellen, Karten, Codeblöcke), prüfen und dokumentieren Sie, dass sie tatsächlich unter eine von WCAG definierte Ausnahme fallen. Bestätigen Sie, dass der umgebende Seiteninhalt (Überschriften, Anweisungen, Navigation) weiterhin korrekt reflowt, auch wenn die eingebettete Komponente dies nicht tut.

Wie man es behebt

Container fester Breite, der das Layout zerstört – Falsch

<!-- 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>

Container fester Breite, der das Layout zerstört – Richtig

<!-- 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 blockiert Zoom – Falsch

<!-- 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 blockiert Zoom – Richtig

<!-- 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 -->

Horizontale Navigationsleiste läuft über – Falsch

<!-- 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>

Horizontale Navigationsleiste läuft über – Richtig

<!-- 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 -->

Datentabelle ohne Reflow-Anpassung – Falsch

<!-- 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>

Datentabelle ohne Reflow-Anpassung – Richtig

<!-- 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 -->

Häufige Fehler

Verwendung von overflow: hidden auf dem <body> oder einem Wrapper auf oberster Ebene, um horizontale Scrollbalken zu unterdrücken, ohne den zugrunde liegenden Überlauf zu beheben: Dies blendet den Scrollbalken aus, aber der Inhalt wird weiterhin abgeschnitten und ist unzugänglich, was arguably schlimmer ist als sichtbarer Überlauf, da der Nutzer keinen Hinweis darauf hat, dass Inhalte jenseits des Viewportrands existieren.
Setzen von max-scale=1 oder user-scalable=no im Viewport-Meta-Tag, um zu verhindern, dass ein mobiles Layout bei hohem Zoom „kaputt aussieht“: Dies deaktiviert die Zoom-Fähigkeit des Nutzers vollständig, was sowohl ein Reflow-Verstoß als auch ein Verstoß gegen WCAG 1.4.4 Resize Text ist.
Anwenden von white-space: nowrap auf Textcontainer, Navigationslisten oder Button-Gruppen ohne breakpoint-spezifische Überschreibung: Dies zwingt Text unabhängig vom verfügbaren Platz in eine einzige Zeile und ist eine der häufigsten Ursachen für horizontalen Überlauf bei 320px.
Verwendung absoluter Pixelwerte in CSS-Grid-Definitionen von grid-template-columns (z. B. grid-template-columns: 300px 600px) ohne responsives Fallback: Bei 320px summieren sich die beiden Spalten auf 900px und laufen ohne Reflow über, sofern eine Media Query die Definition nicht durch 1fr oder 100% ersetzt.
Einbetten von <iframe>-Elementen mit festen width- und height-Attributen, die auf Drittanbieterinhalte (Karten, Videos, Formulare) verweisen: Iframes skalieren nicht automatisch, sodass eine 600px breite eingebettete Karte einen 320px-Viewport überlaufen wird. Umhüllen Sie Iframes mit einem das Seitenverhältnis erhaltenden Container und setzen Sie das Iframe selbst auf width: 100%.
Gestaltung modaler Dialoge und Off-Canvas-Panels mit einer festen Mindestbreite größer als 320px: Ein Modal mit min-width: 500px wird überlaufen und wahrscheinlich seine Schließen-Schaltfläche außerhalb des sichtbaren Bereichs verbergen, wodurch Tastaturnutzer bei kleinen Viewport-Breiten im Dialog gefangen werden.
Behandlung von Codeblöcken und <pre>-Elementen als von Reflow ausgenommen, ohne sie in einen horizontal scrollbaren Container zu legen: Rohe Codeblöcke sind nicht als WCAG-Ausnahme aufgeführt. Auch wenn der Codeinhalt selbst komplex sein mag, muss die umgebende Seite reflowen; der Codeblock sollte unabhängig innerhalb eines overflow-x: auto-Wrappers scrollen und nicht die gesamte Seite zum horizontalen Scrollen zwingen.
Vergessen, authentifizierte und dynamische Zustände zu testen: Viele Teams testen nur die ausgeloggte Startseite. Dashboards, Benutzerprofilseiten, mehrstufige Formulare und per JavaScript geladene Fehlerzustände werden häufig mit Annahmen fester Breiten erstellt und fallen bei Reflow durch, selbst wenn Marketingseiten bestehen.
Verwendung von CSS transform: scale(), um Inhalte visuell zu verkleinern, statt ein echtes responsives Layout zu implementieren: Skalierung reduziert die scheinbare Größe, lässt Inhalte aber nicht reflowen – Text wird winzig und unlesbar, statt in eine lesbare Einspaltendarstellung überzugehen, was sowohl Reflow als auch Resize Text verfehlt.
Die Annahme, dass ein mobil-responsives Design automatisch Reflow besteht: Responsives Design zielt typischerweise auf Breakpoints bei 360px, 768px und 1024px. Der WCAG-Referenzpunkt von 320px ist schmaler als die meisten mobilen Breakpoints, was bedeutet, dass Inhalte, die auf einem Standard-Smartphone korrekt aussehen, bei 320px dennoch überlaufen können. Testen Sie immer exakt bei 320px, nicht bei einer generischen „mobilen“ Größe.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidial-Rundverfügung 2025/10, veröffentlicht im Amtsblatt mit der Nummer 32933 am 21. Juni 2025, legt verbindliche Barrierefreiheitsanforderungen für eine breite Palette von digitalen Dienstanbietern fest, die in der Türkei tätig sind. Die Rundverfügung schreibt für die betroffenen Stellen die Einhaltung internationaler Web-Barrierefreiheitsstandards vor – wobei WCAG 2.1 Stufe AA als Basis dient. WCAG 2.2 Stufe AA, das alle Kriterien von 2.1 einschließlich 1.4.10 Reflow umfasst, wird nachdrücklich empfohlen und ist der Standard, der für den Erhalt des vom Ministerium für Familie und Soziale Dienste (Aile ve Sosyal Hizmetler Bakanlığı) vergebenen Erişilebilirlik Logosu (Barrierefreiheitslogo) erforderlich ist.

Zu den von der Präsidial-Rundverfügung 2025/10 erfassten Stellen gehören öffentliche Institutionen und staatliche Stellen auf allen Ebenen, Banken und Finanzinstitute, Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, E-Commerce-Plattformen, Reisebüros, private Transportunternehmen und Privatschulen, die vom Ministerium für Nationale Bildung (Millî Eğitim Bakanlığı) zugelassen sind. Für jeden dieser Sektoren wird erwartet, dass alle öffentlich zugänglichen digitalen Schnittstellen – Websites, Webanwendungen und mobile Webinhalte – für Menschen mit Behinderungen zugänglich sind, einschließlich derjenigen, die auf Zoom und Viewport-Anpassung angewiesen sind, um Inhalte wahrzunehmen.

WCAG 1.4.10 Reflow ist im türkischen Kontext aus mehreren Gründen besonders relevant. Erstens ist die mobile Internetdurchdringung in der Türkei außergewöhnlich hoch, und ein erheblicher Teil der Nutzer greift über mobile Browser bei unterschiedlichen Zoomstufen auf Regierungsdienste, Bankportale und E-Commerce-Plattformen zu. Ein Terminvergabesystem eines Krankenhauses, das Reflow nicht besteht, kann ältere Patientinnen und Patienten mit Sehbeeinträchtigung daran hindern, eigenständig Konsultationen zu buchen – ein direkter Verstoß sowohl gegen das Barrierefreiheitsrecht als auch gegen den öffentlichen Auftrag der betroffenen Institutionen. Zweitens erfordert das Erişilebilirlik-Logosu-Programm ein Konformitätsaudit, das alle Erfolgskriterien der Stufe AA abdeckt; ein Nichtbestehen von 1.4.10 würde eine ansonsten konforme Website vom Erhalt des Logos ausschließen. Drittens sind für Telekommunikationsunternehmen mit großer Abonnentenbasis barrierefreie Self-Service-Portale und Kontoverwaltungsschnittstellen essenziell – ein Dashboard mit fester Breite, das bei 400% Zoom überläuft, schadet direkt Abonnenten mit Sehbeeinträchtigung, die andernfalls weder ein Ladengeschäft aufsuchen noch eine Support-Hotline anrufen müssten.

Organisationen, die Konformität im Rahmen der türkischen Barrierefreiheitsvorschriften nachweisen möchten, sollten sicherstellen, dass ihre responsiven Designimplementierungen speziell bei der Schwelle von 320 CSS-Pixeln validiert werden, dass keine Viewport-Meta-Tags den Nutzerzoom blockieren und dass alle interaktiven Funktionen – einschließlich Authentifizierungsabläufen, Formularübermittlungen und Dokumentdownloads – ohne horizontales Scrollen vollständig bedienbar bleiben. Die Einbeziehung von Reflow-Tests in eine dokumentierte Barrierefreiheitsprüfungs-Historie wird entscheidend sein, um die Konformität gegenüber Aufsichtsbehörden nachzuweisen und die Berechtigung für das Erişilebilirlik Logosu aufrechtzuerhalten.