Wie erkennt man Barrierefreiheitsprobleme bei Schriftgrößen und Zoom?

Barrierefreiheitsprobleme bei Schriftgrößen und Zoom erkennt man, indem man gezielt prüft, ob Texte auf mindestens 200 % vergrößerbar sind, ohne dass Inhalte abgeschnitten werden, und ob Schriftgrößen in relativen Einheiten wie rem oder em definiert sind. Diese technischen Anforderungen sind in den WCAG-Erfolgskriterien verbindlich festgelegt und gelten für alle Websites, die unter das Barrierefreiheitsstärkungsgesetz (BFSG) fallen. Der folgende Artikel beantwortet die wichtigsten Fragen rund um Standards, typische Fehler, Prüfmethoden und geeignete Tools.

Welche WCAG-Anforderungen gelten für Schriftgrößen und Zoom?

Die WCAG 2.2 definiert in Erfolgskriterium 1.4.4 (Resize Text, Level AA), dass Texte auf bis zu 200 % vergrößert werden können müssen, ohne dass Inhalt oder Funktionalität verloren geht. Erfolgskriterium 1.4.10 (Reflow, ebenfalls Level AA) ergänzt, dass Inhalte bei einer Viewport-Breite von 320 CSS-Pixeln ohne horizontales Scrollen lesbar sein müssen.

Konkret bedeutet das für die Umsetzung:

• Schriftgrößen in relativen Einheiten: Pixel (px) als absolute Einheit blockieren die Browservergrößerung in vielen Fällen. Stattdessen sollten rem, em oder Prozentwerte verwendet werden.
• Kein Sperren des Zooms: Der Meta-Tag <meta name="viewport" content="user-scalable=no"> verhindert aktiv das Zoomen und verstößt gegen WCAG 1.4.4.
• Mindestschriftgröße für Fließtext: Obwohl WCAG keine Mindestgröße in Pixeln vorschreibt, gilt in der Praxis 16 px (bzw. 1 rem) als Orientierungswert für gut lesbaren Fließtext.
• Kontrast bleibt bei Zoom erhalten: Vergrößerte Texte müssen weiterhin die Kontrastanforderungen aus WCAG 1.4.3 erfüllen.

Das BFSG, das seit Juni 2025 für viele Unternehmen verbindlich gilt, orientiert sich an der europäischen Norm EN 301 549, die ihrerseits auf WCAG 2.1 Level AA aufbaut. Wer also die WCAG-Anforderungen an Schriftgröße und Zoom erfüllt, adressiert gleichzeitig zentrale Pflichten aus dem BFSG.

Wie erkennt man fehlerhafte Zoom-Implementierungen auf Websites?

Fehlerhafte Zoom-Implementierungen erkennt man am zuverlässigsten durch eine Kombination aus manuellem Browsertest und automatisierter Code-Analyse. Der schnellste manuelle Test: Öffnen Sie die Website im Browser und erhöhen Sie die Textgröße auf 200 % über die Browsereinstellungen. Werden Texte abgeschnitten, überlappen sich Elemente oder verschwindet Inhalt, liegt ein Verstoß gegen WCAG 1.4.4 vor.

Manuelle Prüfschritte im Browser

Gehen Sie beim manuellen Zoom-Test systematisch vor:

1. Rufen Sie die Website in einem aktuellen Browser auf.
2. Erhöhen Sie die Textgröße in den Browsereinstellungen schrittweise auf 200 %.
3. Prüfen Sie, ob alle Texte noch vollständig sichtbar sind und keine Inhalte abgeschnitten werden.
4. Testen Sie interaktive Elemente wie Buttons, Formulare und Navigationsmenüs auf Bedienbarkeit.
5. Wechseln Sie auf eine Viewport-Breite von 320 px und prüfen Sie, ob horizontales Scrollen notwendig wird (WCAG 1.4.10).

Zoom-Sperren im Quellcode aufspüren

Im HTML-Quellcode sollten Sie gezielt nach dem Viewport-Meta-Tag suchen. Problematisch sind Varianten wie user-scalable=no oder maximum-scale=1. Solche Einträge blockieren die native Zoom-Funktion des Browsers und stellen einen klar identifizierbaren WCAG-Verstoß dar, der sich automatisiert erkennen lässt.

Was sind typische Barrierefreiheitsprobleme bei Schriftgrößen?

Die häufigsten Schriftgrößenprobleme auf Websites sind der Einsatz absoluter Pixelwerte, zu kleiner Basisschriftgrößen und fehlender responsiver Anpassungen. Diese Fehler betreffen besonders Nutzerinnen und Nutzer, die auf Browservergrößerung oder Systemeinstellungen für größere Schrift angewiesen sind, etwa ältere Menschen oder Menschen mit Sehbeeinträchtigungen.

In der Praxis begegnen Prüferinnen und Prüfern folgende Problemmuster besonders häufig:

• Schriftgröße in Pixeln fixiert: CSS-Regeln wie font-size: 12px ignorieren die Nutzereinstellungen im Betriebssystem oder Browser vollständig.
• Zu kleine Basisschriftgröße: Fließtexte unter 14 px sind für viele Nutzergruppen schwer lesbar, auch ohne Sehbeeinträchtigung.
• Zeilenabstand zu gering: WCAG 1.4.12 (Text Spacing) schreibt vor, dass Texte bei erhöhtem Zeilen-, Buchstaben- und Wortabstand nicht abgeschnitten werden dürfen.
• Fehlende responsive Anpassung: Schriftgrößen, die auf dem Desktop gut lesbar sind, werden auf Mobilgeräten nicht automatisch skaliert, wenn keine responsiven CSS-Einheiten genutzt werden.
• Überschriften und Labels zu klein: Formularfelder, Buttons oder Navigationselemente mit sehr kleiner Beschriftung erschweren die Bedienung erheblich.

Viele dieser Probleme entstehen nicht aus Fahrlässigkeit, sondern weil Designvorgaben in absolute Einheiten übersetzt werden, ohne die Auswirkungen auf die Zugänglichkeit zu berücksichtigen.

Wie unterscheiden sich automatisierte und manuelle Prüfmethoden?

Automatisierte Tests prüfen den HTML- und CSS-Code einer Website auf messbare Regelverstöße, etwa gesperrten Zoom oder Schriftgrößen in Pixeln. Manuelle Tests prüfen, ob die Website in der tatsächlichen Nutzung zugänglich ist, zum Beispiel ob Inhalte nach der Vergrößerung noch sinnvoll angeordnet sind. Beide Methoden ergänzen sich und ersetzen sich gegenseitig nicht.

Was automatisierte Tests leisten

Automatisierte Barrierefreiheitstests, die auf Bibliotheken wie axe-core basieren, können zuverlässig erkennen:

• Viewport-Meta-Tags mit Zoom-Sperre
• Schriftgrößen unterhalb definierter Schwellenwerte
• Fehlende oder fehlerhafte CSS-Einheiten
• Verstöße gegen Text-Spacing-Anforderungen (WCAG 1.4.12)

Schätzungen gehen davon aus, dass automatisierte Tests etwa 30 bis 50 % aller WCAG-Verstöße aufdecken können. Für Schriftgrößen- und Zoom-Probleme, die sich auf Code-Ebene manifestieren, ist die Trefferquote in der Regel höher.

Was manuelle Tests leisten

Manuelle Tests decken auf, was Code-Analyse nicht sieht: Ob Texte nach der Vergrößerung visuell überlappen, ob die Lesereihenfolge noch logisch ist oder ob Inhalte zwar technisch vorhanden, aber praktisch nicht erreichbar sind. Die Web Accessibility Initiative (WAI) stellt dazu eine Checkliste für manuelle Schnelltests bereit, die auch ohne tiefe Testerfahrung nutzbar ist. Ein gutes Ergebnis im automatisierten Barrierefreiheits-Test ist eine notwendige, aber keine hinreichende Bedingung für tatsächliche Zugänglichkeit.

Welche Tools helfen beim Erkennen von Schriftgrößen- und Zoomproblemen?

Für das Erkennen von Schriftgrößen- und Zoomproblemen stehen spezialisierte Accessibility-Software-Lösungen, Browser-Entwicklertools und manuelle Testmethoden zur Verfügung. Die Wahl des geeigneten Tools hängt davon ab, ob einzelne Seiten oder ganze Websites systematisch geprüft werden sollen.

• Browser-Entwicklertools: Die Entwicklertools in Chrome, Firefox oder Edge ermöglichen es, CSS-Regeln direkt zu inspizieren und zu prüfen, ob Schriftgrößen in relativen Einheiten definiert sind. Der Quellcode-Viewer zeigt Viewport-Meta-Tags auf einen Blick.
• Axe DevTools (Browser-Extension): Die kostenlose Browser-Erweiterung von Deque Systems prüft die aktuell geöffnete Seite auf WCAG-Verstöße, darunter auch Zoom- und Schriftgrößenprobleme.
• WAVE (Web Accessibility Evaluation Tool): Das Tool von WebAIM visualisiert Barrierefreiheitsprobleme direkt auf der Seite und eignet sich gut für eine erste Einschätzung.
• Automatisierte Accessibility-Software-Plattformen: Für die systematische Prüfung mehrerer Websites oder ganzer Website-Strukturen sind Plattformen geeignet, die Unterseiten scannen, Ergebnisse priorisieren und Berichte exportieren. Diese Tools sind besonders relevant für Agenturen und Compliance-Teams, die viele Websites betreuen.
• Screenreader-Tests: Obwohl Screenreader primär für andere Barrieren relevant sind, helfen sie dabei, zu verstehen, wie stark Zoom-Probleme die Gesamtnavigation beeinflussen.

Kein einzelnes Tool deckt alle Probleme ab. Empfehlenswert ist eine Kombination aus automatisiertem Scan für die schnelle Identifikation von Code-Fehlern und manuellem Browsertest für die Prüfung der tatsächlichen Nutzungserfahrung. Wer eine Website auf Barrierefreiheit prüfen möchte, sollte beide Methoden systematisch einsetzen.

Wann müssen Unternehmen Schriftgrößen- und Zoomprobleme beheben?

Für viele Unternehmen besteht seit Juni 2025 eine gesetzliche Pflicht zur digitalen Barrierefreiheit. Das Barrierefreiheitsstärkungsgesetz (BFSG) verpflichtet Anbieter bestimmter Produkte und Dienstleistungen, ihre digitalen Angebote nach WCAG 2.1 Level AA zugänglich zu gestalten. Schriftgrößen- und Zoomprobleme, die gegen WCAG 1.4.4 oder 1.4.10 verstoßen, sind damit unmittelbar relevant.

Im Einzelnen gilt:

• Öffentliche Stellen: Bundesbehörden und öffentliche Einrichtungen unterliegen bereits seit 2019 bzw. 2021 strengen Barrierefreiheitspflichten nach der BITV 2.0.
• Private Unternehmen im Geltungsbereich des BFSG: Seit dem 28. Juni 2025 müssen Unternehmen, die unter das BFSG fallen, ihre Websites und digitalen Dienste barrierefrei gestalten. Dazu zählen insbesondere E-Commerce-Anbieter, Banken und Telekommunikationsunternehmen.
• Neu gestaltete Websites: Unabhängig von gesetzlichen Fristen sollte jede neu entwickelte oder grundlegend überarbeitete Website von Beginn an auf barrierefreie Schriftgrößen und Zoom-Kompatibilität ausgelegt sein.
• Priorisierung nach Schweregrad: Wenn Ressourcen begrenzt sind, sollten Probleme nach ihrer Auswirkung priorisiert werden. Zoom-Sperren, die grundlegende Funktionen blockieren, sind als kritisch einzustufen und sollten zuerst behoben werden.

Auch wenn keine unmittelbare gesetzliche Pflicht besteht, lohnt sich die Behebung von Schriftgrößen- und Zoomproblemen aus praktischen Gründen: Sie verbessern die Nutzererfahrung für alle Besucherinnen und Besucher, nicht nur für Menschen mit Beeinträchtigungen.

Wie decareto bei der Erkennung von Schriftgrößen- und Zoomproblemen unterstützt

Wir bei decareto haben unsere Accessibility-Software entwickelt, um genau die Probleme sichtbar zu machen, die bei manuellen Prüfungen leicht übersehen werden. Für Schriftgrößen- und Zoomprobleme bietet unsere Plattform konkrete Unterstützung:

• Automatisierter Scan nach WCAG-Standards: Unsere Software prüft Websites auf Zoom-Sperren im Viewport-Meta-Tag, auf Schriftgrößen in absoluten Einheiten und auf Verstöße gegen WCAG 1.4.4, 1.4.10 und 1.4.12, und das auf allen Unterseiten in einem Durchgang.
• Priorisierung nach Schweregrad: Gefundene Probleme werden nach ihrer Auswirkung eingestuft, von kritisch bis geringfügig, damit Sie sofort erkennen, wo dringender Handlungsbedarf besteht.
• Konkrete Handlungsempfehlungen: Zu jedem gefundenen Problem liefern wir verständliche Hinweise zur Behebung, inklusive Verweis auf das betreffende WCAG-Erfolgskriterium und den HTML-Code des problematischen Elements.
• Dauerhafte Überwachung: Hunderte Websites lassen sich kontinuierlich überwachen. Bei Änderungen, die neue Barrieren einführen, erhalten Sie automatische Benachrichtigungen.
• Manuelle Ergänzung möglich: Probleme, die nur manuell erkennbar sind, können direkt im Report dokumentiert und dem Scan-Ergebnis hinzugefügt werden, für ein vollständiges Bild der Barrierefreiheitssituation.
• Reports teilen und exportieren: Fertige Berichte können direkt mit Kunden geteilt oder als PDF exportiert werden, auch mit Whitelabel-Logo für Agenturen.

Ein gutes Ergebnis im decareto-Scan ist ein wichtiger Indikator, ersetzt aber keine vollständige manuelle Prüfung oder rechtliche Beratung. Wir unterstützen Ihre Compliance-Arbeit, indem wir technische Schwachstellen sichtbar machen und Ihnen strukturierte Grundlagen für weitere Maßnahmen liefern. Testen Sie unsere Barrierefreiheits-Software und prüfen Sie Ihre Website noch heute oder registrieren Sie sich jetzt für einen kostenlosen Einstieg.

Dieser Text wurde mit Hilfe von KI erstellt und könnte Fehler beinhalten.

Ähnliche Artikel

• Welche Barrierefreiheitsanforderungen gelten für digitale Dokumente?
• Wie reduziere ich den Aufwand für DSGVO-Website-Prüfungen als Kanzlei?
• Wie hilft ein Barrierefreiheits-Monitoring bei Gesetzeskonformität?
• Was prüft ein WCAG-Test bei Animationen und bewegten Inhalten?
• Wie erkennt man WCAG-Verstöße bei responsiven Websites?