WCAG & BFSG · WCAG-Referenz: Wahrnehmbar

WCAG 1.4.4: Textgröße ändern

Q: Darf ich Schriftgrößen in Pixeln angeben?

Ja, das Kriterium verbietet px nicht. Der Haken: Die Einstellung „Standardschriftgröße“ im Browser wirkt nur auf rem und em. Wer Pixel verwendet, nimmt allen Nutzern diese Möglichkeit und ist auf den Layout-Zoom angewiesen. Für neue Projekte ist rem die bessere Wahl – der Aufwand ist einmalig, der Gewinn dauerhaft.

Von Jakob Sommer Zuletzt geändert am 23. Juli 2026

WCAG 1.4.4 verlangt, dass sich Text ohne Hilfsmittel auf 200 Prozent vergrößern lässt, ohne dass Inhalt oder Funktion verloren geht – nichts darf abgeschnitten werden, überlappen oder unbedienbar werden. Ausgenommen sind nur Untertitel und Bilder von Text; alles andere muss die doppelte Schriftgröße aushalten.

(Englisch: Resize Text. Der BIK-BITV-Test führt das Kriterium unter dem deutlicheren Namen „Text auf 200 % vergrößerbar“.)

Stufe	Prinzip	Teil der WCAG seit	Rechtlich verbindlich?
AA	Wahrnehmbar	2.0 (2008)	Ja – über EN 301 549 in BFSG & BITV

Das Wichtigste in Kürze

200 Prozent ist die Messlatte, nicht das Ziel: Geprüft wird, ob bei doppelter Textgröße noch alles da und bedienbar ist.
Zwei Wege zählen als Nachweis: der Browser-Zoom und die Textgrößen-Einstellung des Browsers. Einer davon muss sauber funktionieren.
Zwei Ausnahmen nennt der Normtext: Untertitel und Bilder von Text.
Der häufigste Verstoß ist der Container mit fester Höhe und overflow: hidden – der Text wächst, die Box nicht, der Rest verschwindet.
px bei Schriftgrößen ist der zweite Klassiker: Der Browser-Zoom greift zwar trotzdem, die Textgrößen-Einstellung des Nutzers aber nicht.
user-scalable=no im Viewport-Meta-Tag ist ein direkter Verstoß und wird von axe und Lighthouse automatisch gemeldet.
Der BITV-Test prüft bei 1280 × 768 Pixeln Fenstergröße in Firefox und Chrome – wer nur in einem Browser testet, hat den Prüfschritt nicht abgedeckt.
1.4.4 ist nicht 1.4.10: 200 Prozent ohne Verlust hier, 400 Prozent mit einspaltigem Umbruch bei Reflow.

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.

Muss meine Seite bei 200 % Zoom funktionieren?

Ja – auf 200 Prozent, ohne dass Inhalt oder Funktion verloren geht, abgeschnitten wird oder überlappt.

Zoomen ist die niederschwelligste aller Sehhilfen – jede Nutzerin hat sie im Browser dabei, ohne Zusatzsoftware, ohne Einrichtung, ohne dass jemand davon erfährt. Genau darum knüpft die Norm daran an: Der Weg über den Browser muss funktionieren, weil er der einzige ist, den praktisch alle gehen können.

Der Normtext ist dabei präziser, als er auf den ersten Blick wirkt. Verlangt wird nicht, dass du eine Schriftvergrößerung anbietest – die kleinen A-A-A-Knöpfe oben rechts, die man auf Behördenseiten findet, sind keine Anforderung, sondern eine mögliche Erfüllungstechnik. Verlangt wird, dass die Seite die Vergrößerung aushält, die der Nutzer ohnehin schon vornehmen kann.

Dabei zählen zwei Mechanismen:

Layout-Zoom (Strg/Cmd + +): Der Browser skaliert alles – Text, Abstände, Bilder, Medienabfragen. Bei 200 Prozent verhält sich ein 1280-Pixel-Fenster wie ein 640-Pixel-Fenster, also ungefähr wie ein Tablet im Hochformat.
Nur-Text-Zoom (in Firefox unter Ansicht → Zoom → Nur Text zoomen, in Chrome über die Schriftgrößen-Einstellung): Nur die Schrift wächst, die Container bleiben. Das ist der härtere Test – und der, der die festen Höhen aufdeckt.

Für die Erfüllung reicht laut Norm einer der beiden Wege. In der Praxis würd ich dir raten, beide durchzuspielen: Der Layout-Zoom findet Layout-Probleme, der Nur-Text-Zoom findet die kaputten Boxen. Und die zweite Art von Fehler ist die, über die Nutzer sich beschweren.

Der vollständige Wortlaut steht im Understanding-Dokument des W3C zu 1.4.4; das deutsche Prüfvorgehen beschreibt der Prüfschritt 1.4.4 des BIK BITV-Tests.

Drei Teaser-Karten nebeneinander. Links bei 100 Prozent Zoom: die Karte zeigt Überschrift, drei Zeilen Text und einen Button, alles passt. In der Mitte, rot markiert, dieselbe Karte bei 200 Prozent mit fester Höhe von 120 Pixeln und overflow hidden: der Text bricht mitten im Wort ab, der Button ist nicht mehr sichtbar, Anmerkung durchgefallen, Inhalt und Funktion verloren. Rechts, grün markiert, dieselbe Karte bei 200 Prozent mit min-height statt height: die Karte ist höher geworden, Text und Button sind vollständig sichtbar, Anmerkung bestanden, der Container wächst mit. — Der Unterschied ist eine einzige CSS-Zeile: `height` kappt den vergrößerten Text, `min-height` lässt die Karte mitwachsen.

Wen betrifft es besonders?

Die größte Gruppe ist die, die sich nie meldet. Menschen mit Sehbehinderung – Makuladegeneration, grauer Star, diabetische Retinopathie – vergrößern routinemäßig, und zwar nicht auf 120, sondern auf 200 bis 400 Prozent. Dazu kommt die weit größere Zahl derer, die schlicht altersweitsichtig sind und den Browser-Zoom als Lesebrille benutzen, ohne sich je als „betroffen“ zu verstehen.

Wer eine Bildschirmvergrößerung wie ZoomText oder die macOS-Zoomfunktion einsetzt, hat zusätzlich das Problem des kleinen Ausschnitts: Was am rechten Rand abgeschnitten wird, ist nicht nur unleserlich, sondern gar nicht auffindbar.

Und dann gibt es die situative Gruppe: der Beamer im Besprechungsraum, das Notebook in der Sonne, die Präsentation, bei der jemand für die hinteren Reihen zoomt. Zoom ist die meistgenutzte Barrierefreiheitsfunktion des Webs – und die einzige, die niemand erst installieren muss.

Richtig & falsch im Code

Der Einstieg ist immer der Viewport. Wer das Zoomen auf Mobilgeräten verbietet, hat das Kriterium gerissen, bevor die erste Zeile CSS geschrieben ist:

<!-- Falsch: Pinch-Zoom auf Mobilgeräten gesperrt -->
<meta name="viewport"
      content="width=device-width, user-scalable=no, maximum-scale=1" />

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

Der zweite Hebel ist die Einheit. px ist nicht verboten – der Layout-Zoom skaliert auch Pixel –, aber die Textgrößen-Einstellung des Browsers greift nur bei rem und em:

/* Falsch: feste Höhe kappt den wachsenden Text */
.teaser {
  height: 120px;
  overflow: hidden;
  font-size: 14px;
}

/* Richtig: relative Größen, Höhe wächst mit dem Inhalt */
.teaser {
  min-height: 7.5rem;
  font-size: 0.875rem;
  line-height: 1.5;
}

Der dritte Hebel sind die Container, die den Text umschließen. Buttons, Navigationspunkte und Badges bekommen gern eine feste Höhe, damit sie sauber ausgerichtet sind – und genau die reißt bei 200 Prozent:

/* Falsch: Button mit fester Höhe, Text zentriert per line-height */
.btn { height: 40px; line-height: 40px; padding: 0 16px; }

/* Richtig: Innenabstand statt Höhe, Text darf umbrechen */
.btn {
  display: inline-flex;
  align-items: center;
  min-height: 2.5rem;
  padding: 0.5rem 1rem;
  line-height: 1.4;
}

Vier Muster fallen bei jedem Audit auf und lassen sich vorbeugend abstellen: height durch min-height ersetzen, overflow: hidden von Textcontainern verbannen, white-space: nowrap nur dort einsetzen, wo der Text nachweislich kurz bleibt, und klebende Kopfleisten mit max-height begrenzen – sonst frisst eine gezoomte Kopfzeile den halben Bildschirm. Die zugehörigen Muster stehen unter Reflow, Zoom & Textabstände.

So testest du es

Fenster auf 1280 × 768 Pixel stellen. Das ist die Ausgangsgröße, mit der der BITV-Test arbeitet. Wer im Vollbild auf einem 27-Zoll-Monitor zoomt, findet die Fehler nicht, weil der Platz sie kaschiert.
Auf 200 Prozent zoomen. In Firefox sind das sechs Mal Strg + +, in Chrome stellst du den Wert im Zoom-Menü direkt ein.
Die Kernabläufe durchspielen, nicht nur die Startseite: Suche, Formular, Warenkorb, Anmeldung. Fehler sitzen dort, wo Text und Bedienelemente in engen Boxen zusammenkommen.
In Firefox und Chrome prüfen. Die beiden Engines runden Layouts unterschiedlich; der Prüfschritt verlangt beide ausdrücklich.
Nur-Text-Zoom hinterher. In Firefox Ansicht → Zoom → Nur Text zoomen aktivieren und erneut vergrößern – das deckt feste Höhen auf, die der Layout-Zoom kaschiert.
Automatisch gegenprüfen: axe und Lighthouse melden user-scalable=no und maximum-scale unter der Regel meta-viewport. Mehr findet kein Werkzeug – der Rest ist Sichtprüfung.

Ob ein meta viewport den Zoom sperrt, prüft der Struktur-Check in Sekunden mit.

Häufiger Fehler in der Praxis

Der mit Abstand häufigste Befund ist die Teaser-Kachel mit fester Höhe. Drei Kacheln nebeneinander sollen gleich hoch sein, also bekommen sie height: 220px und overflow: hidden. Bei 100 Prozent sieht das aufgeräumt aus. Bei 200 Prozent endet die Überschrift mitten im Wort, und der Link darunter ist weg – nicht nur unsichtbar, sondern per Tastatur trotzdem fokussierbar, was die Sache noch schlimmer macht. Die Lösung heißt seit Jahren CSS Grid: Gleiche Höhe entsteht durch die Zeile, nicht durch eine feste Zahl.

Der zweite Klassiker ist die klebrige Kopfzeile. Ein position: sticky-Header mit 80 Pixeln Höhe wird bei 200 Prozent zu 160 Pixeln – auf einem Laptop bleibt dann ein Streifen Inhalt übrig. Wer den Header baut, sollte ihn ab einer bestimmten Fensterhöhe entkleben oder auf eine Zeile eindampfen.

Der dritte ist leiser: abgeschnittene Formularfehler. Die Meldung „Bitte geben Sie eine gültige E-Mail-Adresse ein“ passt bei 100 Prozent in eine Zeile neben das Feld. Bei 200 Prozent braucht sie drei Zeilen, der Container hat aber eine feste Höhe – und weg ist der Hinweis, der 3.3.1 Fehlererkennung eigentlich erfüllen sollte. Ein Kriterium reißt hier ein zweites mit.

Häufige Fragen

Muss ich Knöpfe zum Vergrößern der Schrift anbieten?

Nein. Die A-A-A-Knöpfe auf vielen Behördenseiten sind eine mögliche Erfüllungstechnik, keine Pflicht. Wenn der Browser-Zoom sauber funktioniert, ist das Kriterium erfüllt. Wer solche Knöpfe trotzdem anbietet, muss sie laut BITV-Prüfschritt weit oben platzieren, schrittweise vergrößern lassen und die Rückkehr zur Ausgangsgröße ermöglichen – sonst gilt der Prüfschritt als nicht voll erfüllt.

Zählt der Browser-Zoom überhaupt, oder muss es Textvergrößerung sein?

Der Browser-Zoom zählt. Das W3C nennt ihn ausdrücklich als Weg zur Erfüllung, weil er in allen aktuellen Browsern ohne Zusatzsoftware verfügbar ist. Die Norm schließt nur assistive Technologie aus – also Software, die extra installiert werden muss. Bordmittel des Browsers sind erlaubt.

Darf ich Schriftgrößen in Pixeln angeben?

Ja, das Kriterium verbietet px nicht. Der Haken: Die Einstellung „Standardschriftgröße“ im Browser wirkt nur auf rem und em. Wer Pixel verwendet, nimmt allen Nutzern diese Möglichkeit und ist auf den Layout-Zoom angewiesen. Für neue Projekte ist rem die bessere Wahl – der Aufwand ist einmalig, der Gewinn dauerhaft.

Was ist der Unterschied zu 1.4.10 Reflow?

1.4.4 prüft bei 200 Prozent, ob Inhalt und Funktion erhalten bleiben – ein zweispaltiges Layout darf zweispaltig bleiben, solange nichts abgeschnitten wird. 1.4.10 Reflow geht auf 400 Prozent und verlangt zusätzlich, dass kein Scrollen in zwei Richtungen nötig wird, der Inhalt sich also auf eine Spalte umbricht. Wer 1.4.10 erfüllt, erfüllt 1.4.4 meistens gleich mit.

Gilt das Kriterium auch für PDF-Dateien?

Ja. Die EN 301 549 bezieht Nicht-Web-Dokumente ein, und der BITV-Test kennt einen eigenen Prüfschritt dafür. Bei PDFs hängt die Vergrößerbarkeit am Umfließen (Reflow) im Reader – ein getaggtes, korrekt strukturiertes PDF kann das, ein gescanntes Bild-PDF nicht. Details unter PDF-Barrierefreiheit.