Reflow, Zoom & Textabstände

Deine Seite erfüllt die drei Anpassbarkeits-Kriterien, wenn sich Text auf 200 % vergrößern lässt, der Inhalt bei 320 CSS-Pixeln Breite ohne waagerechtes Scrollen umbricht und größere Textabstände nichts abschneiden. Die Mittel dafür sind kein Sonderwissen, sondern gutes responsives Handwerk: relative Einheiten, flexible Layouts, mitwachsende Container – und kein gesperrtes Pinch-Zoom.

Nicht alle lesen mit Standardgröße. Viele zoomen, vergrößern die Schrift oder erzwingen größere Abstände – wie das konkret aussieht, zeigt der Blick auf Bildschirmvergrößerung & ZoomText. Drei WCAG-Kriterien stellen sicher, dass dabei nichts zerbricht, und es sind genau die, die in Audits gern auffallen – weil sie sich nicht mit einem automatischen Test abhaken lassen. Jedes hat auch eine eigene Referenzseite: 1.4.4, 1.4.10, 1.4.12.

Das Wichtigste in Kürze

• 1.4.4 (AA): Text muss sich auf 200 % vergrößern lassen, ohne dass Inhalt oder Funktion verloren geht.
• 1.4.10 (AA): Inhalt muss bei 320 CSS-Pixeln Breite umbrechen, ohne Scrollen in zwei Richtungen. Für waagerecht scrollende Inhalte gilt spiegelbildlich eine Höhe von 256 CSS-Pixeln.
• 320 px entsprechen 1280 px bei 400 % Zoom – das ist dieselbe Anforderung, nur anders gemessen.
• 1.4.12 (AA) ist ein Robustheitstest, kein Einbau: Deine Seite muss größere Zeilenhöhen und Abstände vertragen, nicht selbst setzen.
• Die Reflow-Ausnahme gilt nur für Inhalte, die zweidimensionales Layout brauchen (Datentabellen, Karten, Diagramme) – und nur für diesen Teil, nicht für die Seite drumherum.
• overflow-x: hidden ist keine Lösung, sondern ein dokumentierter Fehlschlag: Was abgeschnitten wird, ist verloren.
• user-scalable=no und maximum-scale=1 im Viewport-Meta sperren Pinch-Zoom aus – ein klassischer Verstoß.

Die drei Kriterien auf einen Blick

Alle drei sind Stufe AA und damit Teil dessen, was BITV und BFSG verlangen. Und alle drei scheitern typischerweise nicht am ganzen Layout, sondern an drei, vier konkreten Bauteilen – meist Tabellen, Sticky-Headern und Buttons mit fester Größe.

1.4.4 Textgröße ändern (AA)

Text muss sich auf 200 % vergrößern lassen, ohne dass Inhalt oder Funktion verloren geht. Der Schlüssel: relative Einheiten statt fester Pixel.

/* Skaliert mit der Nutzereinstellung */
body { font-size: 1rem; }
h1   { font-size: 2rem; }

/* Bremst die Schriftgrößen-Einstellung aus – vermeiden */
body { font-size: 16px; }

Wer durchgängig rem/em nutzt, hat dieses Kriterium praktisch geschenkt. Drei Feinheiten entscheiden trotzdem über Erfolg oder Misserfolg:

rem ist nicht automatisch sicher. Das verbreitete html { font-size: 62.5% } (damit 1rem = 10px ergibt) ist unbedenklich, weil es die Nutzereinstellung prozentual umrechnet. Ein html { font-size: 10px } dagegen setzt sie hart außer Kraft – dieselbe Optik, gegenteilige Wirkung.

Reine Viewport-Einheiten heben den Zoom auf. font-size: 4vw klingt responsiv, ist für dieses Kriterium aber gefährlich: Beim Zoomen schrumpft der Viewport in CSS-Pixeln, also bleibt die Schrift gleich groß. Der sichere Weg ist clamp() mit einer rem-Untergrenze:

/* Skaliert mit dem Viewport, aber nie unter die Nutzergröße */
h1 { font-size: clamp(1.75rem, 1.2rem + 2.5vw, 3rem); }

Zoom ist nicht gleich Zoom. Chrome und Safari kennen praktisch nur den Seiten-Zoom, der alles skaliert. Firefox bietet unter Ansicht → Zoom → Nur Text zoomen den echten Textzoom – und genau der deckt Bugs auf, die der Seiten-Zoom verdeckt: Buttons, deren Beschriftung herausläuft, Navigationen, die umbrechen, Icons, die neben dem Text stehen bleiben.

1.4.10 Reflow (AA)

Inhalt muss sich auf eine Breite von 320 CSS-Pixeln umbrechen lassen, ohne Scrollen in zwei Richtungen. Für Inhalte, die waagerecht scrollen (etwa eine Zeitleiste), gilt dieselbe Forderung um 90 Grad gedreht: 256 CSS-Pixel Höhe.

Woher die 320 kommen: Ein Fenster von 1280 CSS-Pixeln Breite entspricht bei 400 % Zoom genau 320 CSS-Pixeln nutzbarer Breite. Wer also mobil sauber umbricht, erfüllt in aller Regel auch die Zoom-Anforderung – die Kriterien sind zwei Blickwinkel auf dieselbe Sache.

Die vier häufigsten Bruchstellen

Feste Pixelbreiten. width: 960px an einem Inhaltscontainer erzwingt waagerechtes Scrollen, sobald der Viewport schmaler ist. max-width statt width löst das in einem Zeichen.

Der Flex-/Grid-Klassiker min-width: auto. Flex- und Grid-Elemente schrumpfen standardmäßig nicht unter ihre Inhaltsgröße. Ein langes Wort, eine breite Tabelle oder ein <pre>-Block sprengt damit die Spalte – ohne dass am CSS eine Breite steht:

/* Ohne diese Zeile bricht ein einziges langes Wort das ganze Grid */
.spalte { min-width: 0; }

Lange, nicht umbrechende Zeichenketten. URLs, Dateinamen, Bestellnummern. Die WCAG hat dafür eine eigene Technik (C33); in CSS ist es eine Zeile:

.prose { overflow-wrap: break-word; }

Sticky-Header. Ein 80 px hoher Kopfbereich wird bei 400 % Zoom zu 320 px – und frisst damit mehr als den ganzen sichtbaren Bereich. Das ist formal kein Reflow-Verstoß, aber sehr wohl ein Verlust an Funktion. Die Gegenmaßnahme ist eine Höhen-Media-Query:

/* Bei wenig Höhe scrollt der Header einfach mit */
@media (max-height: 30rem) {
  .site-header { position: static; }
}

overflow-x: hidden ist kein Fix

Der verbreitetste Pfusch: Man findet einen waagerechten Scrollbalken und schaltet ihn ab. Damit ist der Balken weg – und der überstehende Inhalt unerreichbar. Die WCAG führt genau das als Fehlschlag F102 (Inhalt verschwindet beim Reflow und ist nicht mehr verfügbar). Der Scrollbalken war das Symptom, nicht die Krankheit.

Ausnahmen richtig nutzen

Ausgenommen ist Inhalt, der zweidimensionales Layout braucht: Datentabellen, Karten, Diagramme, Videos, Präsentationen, Code mit bedeutungstragender Einrückung. Zwei Dinge werden dabei regelmäßig missverstanden:

1. Die Ausnahme gilt nur für das ausgenommene Element, nicht für die Seite drumherum. Eine breite Tabelle rechtfertigt keine Seite, die insgesamt waagerecht scrollt.
2. Ausgenommen heißt nicht unbedienbar. Wer einen Bereich waagerecht scrollen lässt, muss ihn auch per Tastatur scrollbar machen:

<div role="region" aria-labelledby="tab-titel" tabindex="0" class="tabelle-scroll">
  <h3 id="tab-titel">Fristen nach Bundesland</h3>
  <table> … </table>
</div>

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

Das tabindex="0" ist der entscheidende Teil: Ohne Fokus kann ein scrollbarer Bereich per Tastatur nicht bewegt werden. Mehr dazu unter Komplexe Datentabellen.

Randnotiz – Lesefluss nicht künstlich einengen. Reflow heißt umbrechen, nicht einsperren. Text in eine sehr schmale feste Spalte zu zwängen, schadet beim Zoom mehr, als es nützt. Lass Inhalte die verfügbare Breite nutzen und über die Viewport-Breite atmen.

1.4.12 Textabstände (AA)

Setzt jemand per eigenem Stylesheet oder Browser-Erweiterung größere Abstände, darf nichts abgeschnitten werden oder überlappen. Konkret muss deine Seite diese vier Werte aushalten:

* {
  line-height: 1.5 !important;
  letter-spacing: 0.12em !important;
  word-spacing: 0.16em !important;
}
p { margin-bottom: 2em !important; }

Das ist der komplette Test – und zugleich der am häufigsten missverstandene Punkt: Du musst diese Werte nicht einbauen. Deine Seite muss sie nur überstehen. Wer enger setzt (etwa line-height: 1.4 in einer Überschrift), verstößt nicht – solange die Seite mit den Testwerten nicht zerbricht.

Die typischen Bruchstellen:

• Boxen mit fester Höhe. height: 180px an einer Karte schneidet bei größerer Zeilenhöhe die letzte Zeile ab. min-height statt height – fertig.
• overflow: hidden über Text. Beliebt, um „Überstand“ zu kaschieren; im Test wird daraus Datenverlust.
• Buttons und Chips mit fester Breite. letter-spacing: 0.12em macht jede Beschriftung spürbar breiter. padding statt width.
• Abgeschnittene Zeilen per -webkit-line-clamp. Wenn die Kurzfassung die einzige Fassung ist, geht Inhalt verloren.
• Absolut positionierte Beschriftungen, die bei mehr Zeilenhöhe über anderen Text rutschen.

Zum Testen gibt es Bookmarklets, die genau dieses CSS injizieren – TPGi und die WAI stellen jeweils eines bereit. Genauso gut geht es von Hand: DevTools öffnen, die vier Regeln in das Stylesheet-Panel einfügen, Seite durchscrollen.

Testrezept in fünf Minuten

1. Fenster auf 1280 px Breite bringen (DevTools zeigen die Breite oben rechts an).
2. Auf 400 % zoomen (⌘/Strg und +, fünfmal). Jetzt durch die ganze Seite scrollen: Erscheint irgendwo ein waagerechter Scrollbalken? Verschwindet Inhalt? Bleibt die Navigation erreichbar?
3. In Firefox „Nur Text zoomen“ aktivieren und auf 200 % gehen. Laufen Beschriftungen aus ihren Knöpfen? Überlappen Icons den Text?
4. Textabstands-CSS injizieren und erneut durchscrollen. Wird etwas abgeschnitten?
5. Auf dem Handy Pinch-Zoom ausprobieren. Lässt es sich vergrößern?

Punkt 5 scheitert häufiger als gedacht – und immer an derselben Zeile:

<!-- Falsch: sperrt Pinch-Zoom aus -->
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no" />

<!-- Richtig -->
<meta name="viewport" content="width=device-width, initial-scale=1" />

iOS-Safari ignoriert user-scalable=no inzwischen bewusst, Android-Browser nicht zwingend. Ein Verstoß bleibt es in jedem Fall, weil er die Absicht dokumentiert. Weitere Selbsttests dieser Art sammelt die Seite Barrierefreiheit selbst testen.

Häufige Fehler

• Schriftgrößen in px, die die Nutzereinstellung aushebeln.
• Reine vw-Schriftgrößen – der Zoom bleibt wirkungslos.
• Feste Pixelbreiten für Inhaltscontainer → waagerechtes Scrollen.
• overflow-x: hidden als Pflaster gegen den Scrollbalken (Fehlschlag F102).
• Fehlendes min-width: 0 in Flex-/Grid-Spalten – ein langes Wort sprengt das Layout.
• Feste Höhen mit overflow: hidden, die bei mehr Zeilenabstand Text abschneiden.
• Sticky-Header ohne Höhen-Media-Query, die bei 400 % den Bildschirm füllen.
• Scrollbarer Tabellenbereich ohne tabindex="0" – per Tastatur nicht bewegbar.
• user-scalable=no im Viewport-Meta.
• Text in Bildern, der sich gar nicht skalieren lässt.

Häufige Fragen

Ist Browser-Zoom dasselbe wie „Textgröße ändern“?

Nicht ganz. 1.4.4 zielt auf das reine Vergrößern des Textes, 1.4.10 (Reflow) auf den Seiten-Zoom bis 400 %. Ein gutes responsives Layout deckt beides ab – aber nur der Textzoom in Firefox findet die Buttons, aus denen die Beschriftung herausläuft.

Reicht es, das Fenster auf 320 px schmal zu ziehen?

Fast. Der schmale Viewport prüft dasselbe Ergebnis, aber der echte 400-%-Zoom deckt zusätzlich Dinge auf, die an der Skalierung hängen: Sticky-Elemente, Bilder mit fester Höhe, position: fixed-Overlays. Wer beides macht, ist auf der sicheren Seite.

Muss ich das Nutzer-Stylesheet aus 1.4.12 einbauen?

Nein. Es ist ein Test: Deine Seite muss diese Werte vertragen, nicht selbst setzen. Prüfe mit einem Bookmarklet oder den DevTools.

Meine Datentabelle passt nicht auf 320 px. Ist das ein Verstoß?

Nein, Datentabellen sind ausdrücklich ausgenommen. Aber: Nur die Tabelle darf scrollen, nicht die Seite – und der scrollbare Bereich braucht tabindex="0", damit er auch per Tastatur bewegt werden kann.

Darf ich Pinch-Zoom je deaktivieren?

Nein. maximum-scale=1 oder user-scalable=no sperren Menschen mit Sehschwäche aus und verstoßen gegen die WCAG.

Gilt 1.4.12 auch für Chinesisch oder Japanisch?

Nein. Das Kriterium bezieht sich auf Schriftsysteme, die Wort- und Zeichenabstände in diesem Sinn nutzen. Für CJK-Schriften greifen die Werte nicht.

Fazit

Drei Kriterien sichern die Anpassbarkeit: Text auf 200 % (1.4.4), Reflow auf 320 CSS-Pixel ohne Scrollen in zwei Richtungen (1.4.10) und Robustheit gegen größere Textabstände (1.4.12). Die Mittel sind durchweg gutes responsives Handwerk – relative Einheiten, max-width statt width, min-width: 0 in Flex-Spalten, mitwachsende Container statt fester Höhen – und kein gesperrtes Pinch-Zoom. Wo zweidimensionales Layout wirklich nötig ist, greift die Ausnahme: dann aber sauber gekapselt in einen fokussierbaren, scrollbaren Bereich, nicht als seitenweites Scrollen. Das passt zur Haltung, Text nicht künstlich zu verengen.

Quellen

• Understanding SC 1.4.10 Reflow (W3C WAI – Herleitung der 320/256 CSS-Pixel, Ausnahmen und der Fehlschlag F102)
• Understanding SC 1.4.12 Text Spacing (W3C WAI – die vier Testwerte und ihre Begründung)