WCAG 1.4.10: Reflow (Umbruch)

WCAG 1.4.10 verlangt, dass sich Inhalte auf eine Breite von 320 CSS-Pixeln umbrechen lassen, ohne dass dabei in zwei Richtungen gescrollt werden muss – vertikal scrollen ist erlaubt, horizontal lesen nicht. Ausgenommen sind nur Inhalte, deren Nutzung oder Bedeutung zwei Dimensionen zwingend braucht, etwa Datentabellen und Landkarten.

(Englisch: Reflow; die deutsche Übersetzung spricht von „Umbruch“ oder „Umfluss“.)

Das Wichtigste in Kürze

• 320 × 256 CSS-Pixel sind die Prüfmaße. Sie entsprechen einem 1280 × 1024-Fenster bei 400 % Zoom – daher die krummen Zahlen.
• Zwei Prüfwege sind zulässig, und im BIK-BITV-Test muss nur einer davon bestehen: Smartphone-Breite 320 px ohne Zoom oder Desktop 1280 px mit 400 % Zoom.
• Die Ausnahme gilt für den Inhaltsteil, nicht für die Seite. Eine breite Tabelle darf innerhalb ihres Rahmens scrollen; die Seite drumherum muss trotzdem umbrechen.
• Deutsche Komposita sind eine eigene Fehlerquelle. Wörter wie „Barrierefreiheitsstärkungsgesetz“ sprengen 320 px, wenn hyphens: auto und ein korrektes lang-Attribut fehlen.
• Klebrige Kopfbereiche werden bei 400 % Zoom zur Wand und fressen die halbe Bildschirmhöhe – formal kein 1.4.10-Verstoß, praktisch der zweitgrößte Ärger.
• Wer sauber responsiv baut, erfüllt das Kriterium fast nebenbei – der Aufwand steckt in den Randfällen, nicht im Grundlayout.
• Stufe AA, verbindlich seit der Aufnahme von WCAG 2.1 in die EN 301 549. Im BIK-BITV-Test heißt der Prüfschritt „1.4.10 Inhalte brechen um“.

Abgrenzung – hier steht ein Schwellenwert. Wie du dieses Kriterium zusammen mit den beiden anderen Zoom-Kriterien in einem Durchlauf prüfst, steht unter Reflow, Zoom & Textabstände.

Warum scrollt meine Seite auf dem Handy seitlich?

Wer stark zoomt, liest wie durch ein Fernglas. Muss dabei für jede einzelne Zeile horizontal hin- und hergescrollt werden, wird Lesen zur Sisyphusarbeit – man verliert bei jedem Zeilenwechsel den Anschluss. Deshalb verlangt die Norm: Bei 320 CSS-Pixeln Breite muss der Inhalt einspaltig umbrechen, ohne dass Information oder Funktion verloren geht.

Die Zahlen sind nicht willkürlich. Der Bezugspunkt ist ein Fenster von 1280 × 1024 Pixeln bei 400 % Vergrößerung: 1280 geteilt durch 4 ergibt 320, und 1024 geteilt durch 4 ergibt 256. Der zweite Wert gilt für Inhalte, die horizontal gescrollt werden – etwa eine Zeitleiste –, dort darf dann vertikal nichts nötig sein. In der Praxis prüft fast jeder nur die 320er-Achse.

Ausgenommen sind Inhalte, die für ihre Nutzung oder ihre Bedeutung zwei Dimensionen brauchen:

• Datentabellen mit echten Zeilen-/Spaltenbeziehungen
• Karten und Pläne
• Diagramme und Notensatz
• Code-Blöcke, bei denen der Zeilenumbruch die Bedeutung ändern würde
• Werkzeugleisten von Editoren

Wichtig ist der Zuschnitt dieser Ausnahme: Sie gilt für den betroffenen Inhaltsteil, nicht für die Seite. Eine Tabelle darf in ihrem eigenen Container scrollen (overflow-x: auto), Kopfbereich, Fließtext und Fußzeile drumherum müssen umbrechen. Und eine Tabelle, die nur zum Layouten missbraucht wird, fällt nicht unter die Ausnahme.

Der Normtext samt Randfällen steht im Understanding-Dokument des W3C zu 1.4.10, das deutsche Prüfvorgehen im Prüfschritt „1.4.10 Inhalte brechen um“ des BIK-BITV-Tests.

Wen betrifft es besonders?

Menschen mit Sehbehinderung, die den Browser-Zoom oder eine Vergrößerungssoftware nutzen, sind die eigentliche Zielgruppe – und eine der größten, über die am wenigsten gesprochen wird. Wer eine Sehschärfe von 30 % hat, braucht keine Spezialsoftware, sondern schlicht 300 bis 400 % Zoom. Auf einer Seite ohne Umbruch bedeutet das: Jede Textzeile wird zur Schnitzeljagd nach links und rechts.

Ältere Nutzerinnen und Nutzer zoomen ebenfalls, oft ohne es „Barrierefreiheit“ zu nennen. Und alle mit kleinen Bildschirmen – vom Smartphone im Hochformat bis zum geteilten Fenster auf dem Laptop – profitieren unmittelbar.

Für Menschen mit kognitiven Einschränkungen kommt ein oft übersehener Punkt dazu: Zwei Scrollrichtungen gleichzeitig zu verwalten kostet Arbeitsgedächtnis, das dann beim Inhalt fehlt.

Richtig & falsch im Code

/* Falsch: feste Breite erzwingt horizontales Scrollen */
.wrapper { width: 1200px; }

/* Richtig: fluide Breite mit Obergrenze */
.wrapper { max-width: 75rem; padding-inline: 1rem; }

/* Falsch: Mindestbreite auf Layout-Ebene */
.card-grid { display: grid; grid-template-columns: repeat(3, 400px); }

/* Richtig: Raster bricht selbstständig um */
.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 17rem), 1fr));
}

Die min(100%, 17rem)-Schreibweise ist der Trick, der in vielen Anleitungen fehlt: Ohne sie erzwingt minmax(17rem, 1fr) unterhalb von 272 Pixeln einen Überlauf, weil die Mindestbreite gewinnt.

/* Richtig: lange Wörter, URLs und Adressen umbrechen lassen */
body {
  overflow-wrap: break-word;
  hyphens: auto;          /* braucht ein korrektes lang-Attribut! */
}

/* Richtig: breite Ausnahmen scrollen im eigenen Rahmen */
.tabellen-huelle { overflow-x: auto; }

Die Silbentrennung funktioniert nur, wenn <html lang="de"> gesetzt ist – ohne korrekte Sprachangabe kennt der Browser die Trennregeln nicht. Damit hängt 1.4.10 direkt an 3.1.1 Sprache der Seite, was man dem Kriterium nicht ansieht. Bei deutschen Fachtexten mit Wörtern wie „Barrierefreiheitsstärkungsgesetz“ ist das kein Schönheitsthema, sondern die Ursache echter Überläufe.

/* Falsch: 100vw ignoriert die Bildlaufleiste und erzeugt Überlauf */
.hero { width: 100vw; }

/* Richtig */
.hero { width: 100%; }

So testest du es

1. DevTools öffnen, Geräteleiste einschalten und die Ansicht auf genau 320 × 256 px stellen. Keine Gerätevorlage wählen – die bringen eigene Pixelverhältnisse mit und verfälschen das Ergebnis.
2. Jede Seitenvorlage durchscrollen: Startseite, Artikel, Formular, Suchergebnis, Warenkorb, Login. Erscheint irgendwo eine waagerechte Bildlaufleiste?
3. Den Übeltäter finden, falls ja: In der Konsole document.querySelectorAll('*') durchgehen und Elemente melden lassen, deren scrollWidth breiter ist als der Viewport. Das spart langes Suchen im Inspektor.
4. Zoom-Probe als Gegentest: Fenster auf 1280 px Breite, Browser-Zoom auf 400 %. Hier fallen zusätzlich klebrige Kopfbereiche und Overlays auf, die den Bildschirm zubauen.
5. Ausnahmen prüfen: Scrollen Tabellen, Karten und Code-Blöcke nur innerhalb ihres Rahmens? Ist der Scroll-Container per Tastatur erreichbar?
6. Funktionsprobe: Sind bei 320 px alle Bedienelemente noch da? Ein Menü, das in der schmalen Ansicht Punkte weglässt, verstößt gegen die Bedingung „ohne Verlust von Information oder Funktionalität“.

Häufiger Fehler in der Praxis

Der häufigste Befund ist gar nicht das Layout, sondern eingebetteter Fremdinhalt: das Kartenmodul, der Newsletter-Anmeldeblock des Dienstleisters, das Video mit width="640" im Markup, das Tabellen-Widget aus dem Redaktionssystem. Die eigene Seite bricht sauber um, und ein einziger <iframe> mit fester Breite zieht die ganze Seite in die Breite. Ich guck bei Audits inzwischen zuerst nach iframes, bevor ich überhaupt ins CSS schaue.

Der zweite ist der Redaktionsfehler mit Spätfolgen: Jemand fügt eine Excel-Tabelle als HTML ein, komplett mit width="800" an jeder Zelle. Im Desktop-Layout fällt das nicht auf. Solche Reste findet man am schnellsten, indem man im Inhaltsbestand nach width=" sucht.

Der dritte betrifft den klebrigen Kopfbereich. Bei 400 % Zoom bleibt von 256 CSS-Pixeln Höhe nicht viel übrig, wenn oben eine 80 Pixel hohe Leiste klebt und unten ein Cookie-Banner. Formal ist das kein Verstoß gegen 1.4.10 – aber es macht die Seite unbenutzbar und kollidiert schnell mit 2.4.11 Fokus nicht verdeckt. Die einfache Regel: klebrige Elemente ab einer bestimmten Höhe per Media Query lösen.

Häufige Fragen

Muss ich bei 320 px oder bei 400 % Zoom testen?

Beide Wege sind anerkannt, und im BIK-BITV-Test genügt es, wenn eine der beiden Varianten besteht. In der Praxis lohnen sich trotzdem beide Durchgänge, weil sie unterschiedliche Fehler zutage fördern: Die 320-Pixel-Ansicht zeigt Layoutbrüche, der 400-Prozent-Zoom zeigt Überlagerungen durch fixierte Elemente.

Sind Tabellen von 1.4.10 ausgenommen?

Datentabellen ja, Layouttabellen nein. Die Ausnahme greift, wenn die zweidimensionale Anordnung für Nutzung oder Bedeutung erforderlich ist – bei einer Fahrplantabelle also, bei einem mit Tabellen gebauten Seitenlayout nicht. Der saubere Weg ist ein Scroll-Container um die Tabelle, der per Tastatur erreichbar ist.

Reicht responsives Design, um 1.4.10 zu erfüllen?

Meistens ja – das Grundlayout ist selten das Problem. Übrig bleiben die Randfälle: eingebettete Fremdinhalte, redaktionell gesetzte Pixelbreiten, überlange Wörter und URLs, 100vw-Angaben und Elemente mit min-width. Genau diese vier Kategorien findest du mit dem Testrezept oben.

Gilt 1.4.10 auch für Apps und PDF?

Für native Apps gilt die Anforderung sinngemäß über die EN 301 549, die eigene Kapitel für Software enthält. PDF-Dokumente brechen naturgemäß nicht um; hier ist die Erwartung eine barrierefreie HTML-Fassung als Alternative – mehr dazu unter PDF-Barrierefreiheit.

Was ist der Unterschied zu 1.4.4 Textgröße ändern?

1.4.4 verlangt, dass Text auf 200 % vergrößert werden kann, ohne dass Inhalt oder Funktion verloren geht – dort geht es um die Schriftgröße. 1.4.10 geht darüber hinaus und betrifft das gesamte Layout bei 400 % Vergrößerung. Wer 1.4.10 erfüllt, erfüllt 1.4.4 in aller Regel mit.

Verwandte Themen

• Reflow, Zoom & Textabstände – der Praxis-Leitfaden zum Thema
• 1.4.4 Textgröße ändern – die 200-Prozent-Vorstufe
• 1.4.12 Textabstände – wenn Nutzer die Typografie überschreiben
• 1.3.4 Ausrichtung – flexible Layouts in beiden Orientierungen
• Komplexe Datentabellen – die wichtigste Ausnahme richtig bauen