WCAG 1.4.4: Text vergrößern

Was diese Regel bedeutet

WCAG 1.4.4 Resize Text (Level AA) besagt, dass Text ohne Einsatz von Hilfstechnologien bis auf 200 Prozent vergrößerbar sein muss, ohne dass Inhalte oder Funktionen verloren gehen. Einfach ausgedrückt: Wenn ein Nutzer seinen Browser auf 200 % zoomt oder die Basis-Schriftgröße über Browser- oder Betriebssystemeinstellungen vergrößert, muss der gesamte Text auf der Seite lesbar bleiben und alle Funktionen müssen vollständig erhalten bleiben.

Das Kriterium gilt allgemein für allen auf einer Webseite dargestellten Text, einschließlich Fließtext, Überschriften, Beschriftungen, Button-Text, Platzhaltertext in Formularfeldern, Navigationslinks, Tabelleninhalte und Untertitel. Es gilt nicht für Text, der Teil eines Logos oder Markennamens ist, und auch nicht für dekorativen Text, der keine Information vermittelt und ausschließlich als Bildinhalt dargestellt wird (z. B. ein gescanntes Foto einer handschriftlichen Notiz, bei der der Text selbst nicht der zugängliche Inhalt ist).

Ein „Pass“ erfordert, dass bei 200 % Zoom – erreicht entweder über den integrierten Seitenzoom des Browsers (Strg/Cmd + Plus-Taste oder das Menü Ansicht > Zoom) oder über die Mindestschriftgröße-Einstellung des Browsers – folgende Bedingungen erfüllt sind: Kein Text wird von seinem Container abgeschnitten oder verborgen, kein Text überlappt anderen Text oder interaktive Elemente, es erscheint kein horizontaler Scrollbalken bei voller Viewport-Breite (außer bei Inhalten, die tatsächlich zweidimensionales Scrollen erfordern, wie Karten oder Datentabellen), und alle interaktiven Steuerelemente bleiben bedienbar.

Ein „Fail“ wird vermerkt, wenn feste Pixelwerte Text auf eine Größe festlegen, die nicht wachsen kann, wenn Container feste Höhen verwenden, die überlaufenden Text abschneiden, wenn Viewport-Meta-Tags user-scalable=no oder maximum-scale=1.0 verwenden, um Pinch-to-Zoom auf Mobilgeräten zu blockieren, oder wenn JavaScript Zoom-Gesten abfängt, um Skalierung zu verhindern. Das Kriterium ist ausdrücklich technologieunabhängig: Ob die Implementierung CSS, SVG-Text oder canvas-gerenderten Text verwendet, entscheidend ist das Ergebnis für den Nutzer. Beachten Sie, dass SVG-Text und canvas-gerenderter Text von Natur aus schwer zu vergrößern sind und häufig zusätzliche technische Aufmerksamkeit erfordern.

Warum es wichtig ist

Laut Weltgesundheitsorganisation haben weltweit etwa 2,2 Milliarden Menschen irgendeine Form von Sehbeeinträchtigung. Unter ihnen leidet ein sehr großer Anteil an Sehschwäche – einem Zustand, bei dem das Sehvermögen nicht vollständig mit Brille oder Kontaktlinsen korrigiert werden kann, die Person aber nicht vollständig blind ist. Nutzer mit Sehschwäche stellen ihren Browserzoom routinemäßig auf 150 %, 200 % oder höher ein oder konfigurieren ihr Betriebssystem so, dass Text in einer größeren Basisgröße dargestellt wird. Wenn Websites dieses Verhalten blockieren oder beeinträchtigen, werden diese Nutzer vollständig von den Inhalten ausgeschlossen.

Über diagnostizierte Sehschwäche hinaus wirken sich situative Faktoren praktisch bei jedem Internetnutzer irgendwann aus: kleine Bildschirme, helles Sonnenlicht, Müdigkeit, nachlassende Sehkraft im Alter oder das Lesen in einer fremden Sprache können kleineren Text schwerer erfassbar machen. Ältere Erwachsene – eine weltweit und in der Türkei schnell wachsende Bevölkerungsgruppe – verlassen sich besonders häufig auf Zoom als erste Barrierefreiheitsmaßnahme, bevor sie spezialisierte Hilfstechnologien in Anspruch nehmen.

Betrachten Sie ein konkretes Szenario: Eine Patientin oder ein Patient in den Sechzigern versucht, auf dem Smartphone die Online-Terminbestätigung aus einem Krankenhausportal zu lesen. Das mobile Stylesheet des Krankenhauses setzt die Body-Schriftgröße mit einem festen Pixelwert auf 12px, und das Viewport-Meta-Tag enthält maximum-scale=1.0. Die Person versucht, per Pinch-Zoom zu vergrößern, aber die Oberfläche blockiert. Datum und Fachabteilung können nicht klar genug gelesen werden, um sicher zu sein. Die Person ruft den Helpdesk des Krankenhauses an, was Personalzeit bindet und beim Patienten bzw. bei der Patientin Angst auslöst – ein vollständig vermeidbares Ergebnis, wenn das Kriterium erfüllt worden wäre.

Aus rein kommerzieller Sicht korreliert eine barrierefreie Textskalierung mit allgemeinen Usability-Verbesserungen, von denen alle Nutzer profitieren. Suchmaschinen belohnen außerdem Websites, die gut lesbaren Text in normaler und vergrößerter Größe darstellen, da Googlebot Lesbarkeits-Signale als Teil von Core Web Vitals und Page-Experience-Rankingfaktoren bewertet. Die Behebung von Resize-Problemen verbessert daher gleichzeitig SEO, reduziert den Supportaufwand und erweitert die potenzielle Zielgruppe.

Verwandte Axe-core-Regeln

WCAG 1.4.4 ist in erster Linie ein Kriterium für manuelle Tests. Automatisierte Tools können eine begrenzte Anzahl von Bedingungen markieren, von denen bekannt ist, dass sie die Textvergrößerung verhindern, aber sie können nicht zuverlässig alle Layout-Ergebnisse bei 200 % Zoom simulieren und bewerten. Die folgenden Bedingungen sind diejenigen, die automatisierte Tools zu erkennen versuchen und die eine manuelle Nachprüfung erfordern:

• Viewport-Meta-Tag blockiert Zoom (manuelle Prüfung erforderlich): Axe-core enthält die Regel meta-viewport, die jedes <meta name='viewport'>-Tag markiert, das user-scalable=no setzt oder maximum-scale auf einen Wert von 1,0 oder weniger festlegt. Dies ist das eine Szenario, in dem eine vollständig automatisierte Erkennung möglich ist, da der Verstoß deklarativ ist und nicht vom Layout-Ergebnis abhängt. Allerdings kann selbst diese Regel nicht feststellen, ob eine Website JavaScript verwendet, um Zoom programmgesteuert zu verhindern, sodass eine manuelle Verifizierung immer erforderlich ist.
• Feste Schriftgrößen in Pixeln (manuelle Prüfung erforderlich): Automatisierte Tools können melden, wenn CSS-font-size-Werte in absoluten Pixeleinheiten (px) statt in relativen Einheiten (em, rem, % oder viewport-relative Einheiten) gesetzt sind. Moderne Browser überschreiben jedoch absolute Pixel-Schriftgrößen, wenn der Nutzer seine Standard-Browserschriftgröße ändert, sodass ein Pixelwert allein keinen garantierten Fehler darstellt – es hängt vom Browserverhalten und davon ab, ob die Website font-size-Vererbung respektiert. Eine manuelle Inspektion der berechneten Styles und eine visuelle Überprüfung sind erforderlich, um einen tatsächlichen Fehler zu bestätigen.
• Inhaltsüberlauf und Abschneiden bei 200 % Zoom (nur manuell): Kein automatisiertes Tool kann eine Seite zuverlässig bei 200 % rendern und bewerten, ob der gesamte Text sichtbar bleibt und alle interaktiven Elemente bedienbar bleiben. Dies erfordert, dass eine menschliche Testperson den Browserzoom einstellt, durch die Seite scrollt und jeden Inhaltsbereich überprüft. Automatisierte Tools haben keinen Zugriff auf den gerenderten Zustand nach dem Zoom.
• Text in Bildern und Canvas (nur manuell): Text, der in Rasterbilder eingebettet ist (<img>-Tags mit Screenshots von Text) oder auf ein <canvas>-Element gerendert wird, kann vom Browser überhaupt nicht vergrößert werden. Automatisierte Tools können das Vorhandensein von Canvas-Elementen zur manuellen Überprüfung markieren, aber sie können nicht feststellen, ob diese Canvas-Elemente bedeutungsvollen Text enthalten, den der Nutzer lesen muss.

Wie man testet

1. Führen Sie zuerst einen automatisierten Scan aus. Öffnen Sie die Seite in Chrome oder Firefox und führen Sie axe DevTools (Browser-Erweiterung) oder Lighthouse (Chrome DevTools, Registerkarte Lighthouse) aus. Achten Sie speziell auf den Verstoß gegen die meta-viewport-Regel. Wenn markiert, notieren Sie dies als kritischen Fehler. Prüfen Sie außerdem das CSS-Audit auf font-size-Deklarationen in px-Einheiten, die in den axe-Best-Practice-Warnungen erscheinen.
2. Prüfen Sie das Viewport-Meta-Tag im Quelltext. Öffnen Sie die DevTools (F12), gehen Sie auf den Tab „Elements“ und suchen Sie nach meta name='viewport'. Lesen Sie das content-Attribut sorgfältig. Wenn es user-scalable=no, user-scalable=0 oder maximum-scale=1 (oder einen Wert kleiner als 2) enthält, ist dies ein direkter Verstoß gegen 1.4.4.
3. Stellen Sie den Browserzoom auf 200 %. Drücken Sie in Chrome oder Firefox Strg + Plus (Windows/Linux) oder Cmd + Plus (macOS) wiederholt, bis die Browser-Zoomanzeige 200 % anzeigt. Alternativ gehen Sie zu Ansicht > Vergrößern. In Safari unter macOS verwenden Sie Ansicht > Vergrößern. Verwenden Sie für diesen Test keine Anzeige-Skalierung auf Betriebssystemebene – verwenden Sie ausdrücklich den Browserzoom.
4. Scrollen Sie bei 200 % Zoom durch alle Seitensektionen. Scrollen Sie systematisch von oben nach unten. Achten Sie auf: Text, der von seinem Container abgeschnitten oder verborgen wird, Text, der aus seiner Box herausläuft und benachbarte Inhalte überlappt, Formularbeschriftungen, die hinter ihren Eingabefeldern verschwinden, Buttons, deren Text abgeschnitten ist, Dropdown-Menüs, die aus dem Bildschirm herausragen und nicht in den sichtbaren Bereich gescrollt werden können, und Modaldialoge, die den Viewport überschreiten und nicht gescrollt werden können.
5. Testen Sie alle interaktiven Funktionen bei 200 % Zoom. Aktivieren Sie jedes Navigationsmenü, öffnen Sie alle Modale, senden Sie Formulare ab, lösen Sie Tooltips und Popovers aus und interagieren Sie mit allen Karussells oder Akkordeons. Vergewissern Sie sich, dass all dies vollständig bedienbar bleibt – nicht nur visuell vorhanden.
6. Testen Sie mit NVDA + Firefox (Windows). Aktivieren Sie NVDA und öffnen Sie Firefox bei 200 % Zoom. Navigieren Sie mit der Tab-Taste und den Pfeiltasten. Bestätigen Sie, dass fokussierbare Elemente Fokus erhalten, dass Fokusindikatoren sichtbar sind (Überschneidung mit WCAG 2.4.7, aber nützlich zu prüfen) und dass die Lesereihenfolge bei vergrößerter Darstellung der visuellen Reihenfolge entspricht.
7. Testen Sie mit VoiceOver + Safari (macOS/iOS). Aktivieren Sie VoiceOver. Gehen Sie unter iOS zu Einstellungen > Bedienungshilfen > Anzeige & Textgröße und aktivieren Sie „Größerer Text“. Navigieren Sie auf derselben Seite und überprüfen Sie die inhaltliche Integrität. Verwenden Sie außerdem die Pinch-to-Zoom-Geste, um zu bestätigen, dass sie nicht blockiert ist.
8. Testen Sie die Mindestschriftgröße des Browsers. Gehen Sie in Firefox zu Einstellungen > Allgemein > Schriftarten und Farben und setzen Sie die Mindestschriftgröße auf 24px. Laden Sie die Seite neu und prüfen Sie, ob aller Text diese Mindestgröße erreicht und ob das Layout nicht zerbricht. Dies testet einen anderen Vektor desselben Kriteriums.
9. Testen Sie mit JAWS + Chrome (Windows). Öffnen Sie die Seite in Chrome bei 200 % Zoom mit aktivem JAWS. Verwenden Sie die JAWS-Lesebefehle (Einfg + Pfeil nach unten, um ab Cursor zu lesen), um zu bestätigen, dass alle Textinhalte vorgelesen werden und keine Inhalte aufgrund von Overflow-Clipping übersprungen werden.

Wie man es behebt

Viewport-Meta-Tag blockiert Zoom — Falsch

<!-- WRONG: user-scalable=no prevents pinch-to-zoom on mobile,
     directly violating WCAG 1.4.4 -->
<meta name='viewport' content='width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no'>

Viewport-Meta-Tag blockiert Zoom — Richtig

<!-- CORRECT: Remove user-scalable=no and do not cap maximum-scale below 2.
     Allowing zoom to at least 2 (200%) satisfies WCAG 1.4.4. -->
<meta name='viewport' content='width=device-width, initial-scale=1.0'>

Feste Pixel-Schriftgrößen — Falsch

<!-- WRONG: font-size in px ignores the user's browser font-size preference.
     If the user sets a larger default, px values override that preference. -->
<style>
  body {
    font-size: 14px;
  }
  h1 {
    font-size: 24px;
  }
  .caption {
    font-size: 11px;
  }
</style>
<p>Your appointment is confirmed.</p>

Feste Pixel-Schriftgrößen — Richtig

<!-- CORRECT: Use rem units relative to the root font size (typically 16px browser default).
     1rem = 16px by default, but scales with user preference.
     Setting font-size on :root in % rather than px also respects user settings. -->
<style>
  :root {
    font-size: 100%; /* inherits browser default, typically 16px */
  }
  body {
    font-size: 0.875rem; /* ~14px at default, but scales with user preference */
  }
  h1 {
    font-size: 1.5rem; /* ~24px at default */
  }
  .caption {
    font-size: 0.75rem; /* ~12px at default — still scalable */
  }
</style>
<p>Your appointment is confirmed.</p>

Container mit fester Höhe, die Text abschneiden — Falsch

<!-- WRONG: A fixed height with overflow:hidden will clip enlarged text.
     At 200% zoom, the text grows but the box does not, hiding content. -->
<style>
  .card {
    height: 120px;
    overflow: hidden;
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

Container mit fester Höhe, die Text abschneiden — Richtig

<!-- CORRECT: Use min-height instead of height so the container grows
     with the content when text is enlarged. -->
<style>
  .card {
    min-height: 7.5rem; /* sets a minimum but allows growth */
    overflow: visible; /* or remove overflow:hidden entirely */
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

In Bilder eingebetteter Text — Falsch

<!-- WRONG: A banner image containing text cannot be resized by the browser.
     Even with alt text, the visual text is inaccessible at high zoom levels. -->
<img src='promo-banner-with-text.jpg' alt='50% indirim — sadece bu hafta sonu'>

In Bilder eingebetteter Text — Richtig

<!-- CORRECT: Use real HTML text over a background image so the browser
     can resize it. The image is decorative background; text is live HTML. -->
<div class='promo-banner' role='region' aria-label='Promosyon'>
  <p class='promo-text'>50% İndirim &mdash; Sadece Bu Hafta Sonu</p>
</div>
<!-- CSS sets the background image on .promo-banner, while .promo-text
     uses rem font-size and contrasts safely against the background. -->

Häufige Fehler

• Hinzufügen von user-scalable=no zum Viewport-Meta-Tag, um „Layout-Brüche“ auf Mobilgeräten zu verhindern — dies ist ein direkter, testbarer Verstoß gegen 1.4.4 und darf niemals verwendet werden. Beheben Sie das Layout, anstatt die Zoom-Möglichkeit der Nutzer zu unterdrücken.
• Setzen von maximum-scale=1.0 oder eines Werts unter 2.0 — selbst ohne user-scalable=no verhindert eine Begrenzung des Zooms auf 1,0 oder 1,5, dass Nutzer 200 % erreichen, und verfehlt das Kriterium.
• Verwendung von JavaScript-Event-Listenern, um event.preventDefault() bei Pinch-Zoom- oder Wheel-Events aufzurufen — das programmgesteuerte Blockieren des nativen Zooms ist funktional gleichbedeutend mit dem Ansatz über das Viewport-Meta-Tag und verstößt gegen dasselbe Kriterium.
• Setzen von font-size in Pixeln auf dem <html>- oder <body>-Element und anschließende Verwendung von em-Einheiten für alles andere — wenn die Root-Schriftgröße in px festgelegt ist, sind alle em/rem-Nachfahren ebenfalls faktisch fest und reagieren nicht auf die Schriftgrößenvorgabe des Browsers.
• Verwendung von height statt min-height bei Kartenkomponenten, Sidebars oder Modal-Bodies — bei 200 % Zoom läuft vergrößerter Text aus Boxen mit fester Höhe heraus und wird durch overflow: hidden abgeschnitten, wodurch kritische Inhalte verborgen werden.
• Platzierung wichtiger Texte ausschließlich in <canvas>-Elementen — canvas-gerenderter Text ist ein rasterisiertes Bitmap und kann nicht über die Textvergrößerungs- oder Zoom-Mechanismen des Browsers skaliert werden. Jeder bedeutungsvolle Text, den ein Nutzer lesen muss, muss als echter HTML-Text oder zumindest als zugänglicher Alternativtext verfügbar sein.
• Verwendung von SVG-<text>-Elementen mit absoluten Koordinaten und ohne viewBox-Skalierung — SVG-Text kann skalierbar sein, wenn das SVG ein viewBox verwendet und mit relativen Einheiten dimensioniert ist, aber SVG-Text mit festen x-, y-, font-size-Attributen in Pixeln innerhalb eines SVG mit fester width und height wird nicht in allen Browsern mit dem Browserzoom vergrößert.
• Die Annahme, dass der Browserzoom das Kriterium automatisch erfüllt, und Verzicht auf manuelle Tests — der Browserzoom skaliert die gesamte Seite einschließlich Bilder und Layout, aber Text, der bei 100 % bereits zu klein, abgeschnitten oder überlappend war, wird bei 200 % zu einem noch größeren Problem. Eine manuelle Überprüfung bei vergrößertem Zoom ist immer erforderlich.
• Vergessen, eingebettete Widgets von Drittanbietern zu testen — Chat-Widgets, Zahlungs-Iframes, Cookie-Einwilligungsbanner und Analyse-Overlays werden häufig von Drittanbietern mit festen px-Größen entwickelt und können Zoom blockieren. Auch wenn der Code von Dritten stammt, gilt das Kriterium für die gesamte Seite, wie sie dem Nutzer ausgeliefert wird.
• Behebung des Desktop-Layouts für Zoom, aber Vernachlässigung des mobilen Breakpoints — viele Teams testen Zoom auf dem Desktop und erklären Erfolg, aber mobile Viewports bei 200 % Zoom stellen eine eigene Reihe von Layout-Herausforderungen dar, insbesondere für Navigationsmenüs, Sticky-Header und untere Navigationsleisten, die von festen Pixelhöhen abhängen.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die Präsidialverfügung 2025/10 der Türkei, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die Web- und mobile Barrierefreiheit für einen definierten Kreis von Organisationen fest, die in der Türkei tätig sind. Die Verfügung verweist auf international anerkannte Barrierefreiheitsstandards – und richtet die türkischen Anforderungen damit faktisch an WCAG 2.1 und WCAG 2.2 Level AA als Maßstab für Konformität aus.

WCAG 1.4.4 Resize Text ist ein Kriterium auf Level AA, und die Konformität mit Level AA ist die Schwelle, die erforderlich ist, um das Barrierefreiheitslogo (Erişilebilirlik Logosu) zu erhalten, das vom Ministerium für Familie und Sozialdienste (Aile ve Sosyal Hizmetler Bakanlığı) vergeben wird. Das Barrierefreiheitslogo ist sowohl ein öffentliches Vertrauenssignal als auch ein regulatorischer Kontrollpunkt – Organisationen, die der Verfügung unterliegen und das Logo anzeigen oder Konformität gegenüber Prüfern nachweisen möchten, müssen alle Kriterien auf Level AA erfüllen, einschließlich 1.4.4.

Zu den von der Präsidialverfügung 2025/10 erfassten Kategorien von Einrichtungen gehören: öffentliche Institutionen und Behörden auf allen Ebenen der Regierung; E-Commerce-Plattformen und Online-Marktplätze; Banken und Finanzdienstleister, die von der Bankenaufsichts- und Regulierungsbehörde (BDDK) reguliert werden; Krankenhäuser, Gesundheitszentren und andere Gesundheitseinrichtungen mit digitalen, patientenorientierten Diensten; Telekommunikationsanbieter mit 200.000 oder mehr Abonnenten; Reisebüros und Online-Reiseplattformen; private Transportunternehmen, die digitale Ticket- oder Reservierungsdienste anbieten; sowie Privatschulen und Bildungseinrichtungen, die vom Bildungsministerium (Millî Eğitim Bakanlığı, MoNE) autorisiert sind.

Für jede dieser Einrichtungstypen ist die praktische Bedeutung von 1.4.4 erheblich. Ein Online-Banking-Portal einer Bank, das Pinch-to-Zoom auf Mobilgeräten blockiert, ist nicht nur ein Usability-Fehler – es ist eine regulatorische Nichtkonformität, die zu Prüfungsfeststellungen oder zum Ausschluss aus dem Barrierefreiheitslogo-Programm führen kann. Ein Terminbuchungssystem eines Krankenhauses, das feste Pixel-Schriftgrößen in abschneidenden Containern verwendet, verfehlt es, Patientinnen und Patienten mit Sehschwäche zu bedienen, und verfehlt gleichzeitig seine Verpflichtungen aus der Verfügung. Eine Einschreibungsplattform einer Privatschule, die Text in Bilder einbettet, statt skalierbaren HTML-Text zu verwenden, ist in ähnlicher Weise nicht konform.

Organisationen sollten WCAG 1.4.4 nicht als enges technisches Kontrollkästchen behandeln, sondern als grundlegende Erwartung an den Respekt gegenüber Nutzerinnen und Nutzern mit Sehbeeinträchtigungen – eine Erwartung, auf die türkisches Recht, internationale Best Practices und grundlegende Usability gleichermaßen hinauslaufen. Das Overlay-SDK von Accsible unterstützt die Einhaltung der Anforderungen zur Textvergrößerung, indem es konfigurierbare Schriftgrößen-Steuerungen bereitstellt, mit denen Endnutzer die Textgröße unabhängig vom Browserzoom erhöhen können und so eine zusätzliche Unterstützungsschicht oberhalb der Basisanforderungen bieten, die Websites selbst umsetzen müssen.