WCAG-Erfolgskriterien · Level AA
WCAG 1.4.5: Bilder von Text
WCAG 1.4.5 verlangt, dass Informationen vermittelnder Text als echter Text und nicht als Bild von Text dargestellt wird, außer wenn eine bestimmte visuelle Darstellung wesentlich ist oder das Bild vom Nutzer visuell angepasst werden kann. Dieses Kriterium ist entscheidend für Nutzer, die Text vergrößern, umfärben oder den Zeilenumbruch anpassen müssen, um ihn bequem lesen zu können.
Was diese Regel bedeutet
WCAG 1.4.5 — Bilder von Text (Level AA) besagt, dass, wenn dieselbe visuelle Darstellung mit echtem Text erreicht werden kann, echter Text anstelle eines Bildes mit Text verwendet werden muss. Ein Bild von Text ist jedes Bild, bei dem Textzeichen der primäre übermittelte Inhalt sind – zum Beispiel ein JPEG einer Überschrift, ein PNG-Banner mit einem Slogan oder ein GIF-Logo, das einen Markennamen in einer stilisierten Schrift ausschreibt.
Die Unterscheidung zwischen Bestehen und Nichtbestehen ist eindeutig: Wenn die Information durch Auszeichnen tatsächlicher Zeichen in HTML und deren Gestaltung mit CSS zur Erreichung desselben Aussehens vermittelt werden könnte, ist die Verwendung eines Bildes stattdessen ein Fehler. Die Regel betrifft nicht dekorative Bilder oder Fotografien, die zufällig Text in der Szene enthalten (wie etwa ein Straßenschild auf einem Foto). Sie zielt auf Bilder ab, bei denen der Text selbst der beabsichtigte Inhalt ist.
WCAG definiert zwei offizielle Ausnahmen, bei denen Bilder von Text zulässig sind:
- Wesentliche Ausnahme: Die konkrete visuelle Darstellung ist für die zu vermittelnde Information wesentlich. Das klassische Beispiel ist ein Logotyp – bei dem die spezifische Darstellung der Buchstabenformen untrennbar mit der Markenidentität verbunden ist. Ein Unternehmenslogo, bei dem die stilisierten Buchstabenformen die Marke SIND, kann als Bild bestehen bleiben.
- Anpassbare Ausnahme: Das Bild von Text kann visuell an die Anforderungen der Nutzer angepasst werden. Das bedeutet, dass der Nutzer Schriftart, Größe, Farbe und Hintergrund des Textes im Bild ändern kann. In der Praxis wird diese Ausnahme von realen Implementierungen fast nie erfüllt, da die meisten Bilder nicht dynamisch an Nutzerpräferenzen neu gerendert werden können.
Wichtig ist, was dieses Kriterium NICHT verlangt: Es verbietet nicht alle Bilder, die Text enthalten. Ein Foto eines historischen Dokuments, ein Screenshot als Beweismittel oder ein Diagrammbild, bei dem Achsenbeschriftungen Teil der Datenvisualisierung sind, sind nicht das primäre Ziel dieser Regel, obwohl Alternativtext (WCAG 1.1.1) ihren Inhalt weiterhin beschreiben muss. Der Fokus liegt auf Fällen, in denen ein Designer sich entschieden hat, gestalteten Text als Raster- oder Vektorbild darzustellen – aus rein ästhetischen Gründen –, obwohl CSS dasselbe Ergebnis erzielen könnte.
HTML-Elemente, die am häufigsten mit Verstößen in Verbindung gebracht werden, sind <img>-Tags, die für Überschriften, Banner, Call-to-Action-Buttons, Navigationsbeschriftungen, hervorgehobene Zitate und Werbetexte verwendet werden. SVG-Dateien, die Text als Pfade einbetten (anstatt <text>-Elemente zu verwenden), sind ebenfalls problematisch, da diese Zeichen vom Browser nicht ausgewählt, in der Größe verändert oder umbrochen werden können.
Warum das wichtig ist
Wenn Text in ein Rasterbild eingebettet ist, wird er zu einer festen Bitmap. Der Browser kann das Bild vergrößern oder verkleinern, aber er kann den Text nicht umbrechen, seine Schriftart nicht ändern, seine Strichstärke nicht erhöhen oder seinen Farbkontrast über das hinaus verändern, was bereits in die Pixel eingebrannt ist. Dies schafft erhebliche Barrieren für mehrere Gruppen von Menschen mit Behinderungen.
Nutzer mit Sehbehinderung verlassen sich typischerweise auf Browser-Zoom, Textskalierung des Betriebssystems oder spezielle Vergrößerungssoftware. Echter Text skaliert bei jedem Zoom-Level scharf; ein Bild von Text wird unscharf und pixelig und wird bei starker Vergrößerung unleserlich. Weltweit haben etwa 2,2 Milliarden Menschen irgendeine Form von Sehbeeinträchtigung, und viele von ihnen nutzen Zoom oder Vergrößerung als primäre Bewältigungsstrategie statt eines Screenreaders.
Nutzer mit Legasthenie oder anderen Lesebehinderungen verwenden häufig Browser-Erweiterungen oder unterstützende Technologien, um Schriftarten zu überschreiben, den Zeichenabstand zu vergrößern und auf kontrastreiche Farbschemata umzuschalten. Keine dieser Anpassungen funktioniert bei Bildern von Text – die Pixel sind unveränderlich. Ein Nutzer, der OpenDyslexic oder eine weit gesperrte serifenlose Schrift benötigt, kann diese schlicht nicht auf eine als PNG gerenderte Überschrift anwenden.
Nutzer, die auf benutzerdefinierte Farbschemata angewiesen sind – darunter Menschen mit Photophobie, Migräneerkrankungen oder Kontrastempfindlichkeiten – stellen ihr Betriebssystem möglicherweise auf einen Hochkontrast- oder invertierten Farbmodus ein. CSS-Text reagiert auf diese systemweiten Überschreibungen; Bildtext nicht und kann tatsächlich schwerer lesbar werden, wenn Farben unerwartet invertiert werden.
Betrachten wir ein konkretes Szenario: Eine türkische E-Commerce-Website rendert ihre Kampagnenüberschriften als JPEG-Bilder, um die im Brand Style Guide verwendete Display-Schrift zu erhalten. Ein Nutzer mit Sehbehinderung zoomt seinen Browser auf 200 %. Die Produktbilder skalieren akzeptabel hoch, aber die Kampagnenüberschrift – ein Bild – wird zu einem verschwommenen Pixelbrei. Der Nutzer kann die Aktion nicht lesen und verpasst das Angebot. Wäre dieselbe Schrift über @font-face eingebunden und auf ein echtes <h2>-Element angewendet worden, bliebe der Text bei jedem Zoom-Level scharf, da vektorbasierte Schriftrendering unendlich skaliert.
Über die Barrierefreiheit hinaus hat die Verwendung von echtem Text messbare SEO-Vorteile. Suchmaschinen-Crawler indexieren Textknoten direkt; sie können den Textinhalt von Bildern ohne OCR nicht zuverlässig extrahieren. Eine in ein PNG eingebettete Überschrift ist für Googles Ranking-Algorithmus unsichtbar. Der Umstieg auf echten Text kann die Keyword-Indexierung und das Seitenranking für denselben Inhalt verbessern.
Verwandte Axe-core-Regeln
WCAG 1.4.5 erfordert manuelle Tests. Es gibt keine einzelne automatisierte axe-core-Regel, die Bilder von Text zuverlässig erkennt, aus den unten erläuterten Gründen.
- Manuelle Tests erforderlich – keine dedizierte automatisierte Regel: Automatisierte Tools können erkennen, dass ein
<img>-Element existiert und dass es einalt-Attribut hat, aber sie können nicht feststellen, ob der visuelle Inhalt dieses Bildes hauptsächlich gerenderter Text ist. Dies würde Bilderkennung/OCR für jedes Bild auf der Seite erfordern, was rechenintensiv und kontextabhängig ist. Ein Tool, das eine Seite scannt, kann nicht zwischen einem Foto, das zufällig ein Schild mit Wörtern enthält, und einer bewusst gerenderten Überschriften-Grafik unterscheiden. Menschliches Urteil ist erforderlich, um zu bewerten, ob ein bestimmtes Bild zu dem Zweck existiert, stilisierten Text darzustellen, der stattdessen als echter HTML-Text mit CSS-Styling ausgezeichnet werden könnte. - Teil-Signal aus Farbkontrast-Regeln: Axe-core-Regeln wie
color-contrastwerden nicht bei in Bildern eingebettetem Text ausgelöst, da sie auf DOM-Textknoten und berechneten CSS-Farbwerten arbeiten. Wenn ein Bild von Text unzureichenden Kontrast hat, wird die automatisierte Kontrastprüfung dies stillschweigend übersehen. Das bedeutet, dass Bilder von Text gleichzeitig sowohl 1.4.5 als auch 1.4.3 (Kontrast Minimum) verletzen können, ohne dass eine automatisierte Warnung erfolgt – ein starkes Argument für gründliche manuelle Audits. - SVG Text-als-Pfade: Wenn ein SVG Text beim Export als Umrisspfade (
<path>-Elemente) statt als<text>-Elemente ausgibt, hat axe-core keine Möglichkeit zu erkennen, dass die Pfade Wörter bilden. Eine manuelle Inspektion des SVG-Quellcodes ist notwendig, um festzustellen, ob Text in Pfade umgewandelt wurde und ob er stattdessen ein echtes<text>-Element mit einer Webschrift sein sollte.
Wie man testet
- Führen Sie einen automatisierten Scan als Ausgangsbasis durch. Verwenden Sie axe DevTools (Browser-Erweiterung) oder Lighthouse in den Chrome DevTools, um alle auf der Seite gemeldeten Probleme zu identifizieren. Obwohl keines der Tools eine dedizierte 1.4.5-Regel hat, können die Scan-Ergebnisse verwandte Probleme wie fehlenden
alt-Text bei Bildern oder unzureichenden Farbkontrast bei Textknoten aufzeigen. Notieren Sie alle markierten Bilder – diese werden zu Kandidaten für die manuelle Überprüfung. - Überprüfen Sie alle Bilder auf der Seite visuell. Öffnen Sie die Seite in einem Browser und betrachten Sie systematisch jedes
<img>-Element, jedes Inline-SVG, jedes CSS-Hintergrundbild und jedes Canvas-Element. Fragen Sie sich bei jedem: Ist der Hauptzweck dieses Bildes, Text anzuzeigen? Wenn ja, fahren Sie mit dem nächsten Schritt fort. - Prüfen Sie, ob CSS dasselbe Ergebnis erzielen könnte. Fragen Sie sich bei jedem in Schritt 2 identifizierten Bild: Könnten eine Webschrift (
@font-face) kombiniert mit CSS-Eigenschaften (Farbe, Textschatten, Zeichenabstand, Verlaufshintergrund) ein visuell gleichwertiges Ergebnis erzeugen? Wenn die Antwort ja ist, ist das Bild von Text ein Fehler, sofern die Logotyp-Ausnahme nicht greift. - Überprüfen Sie Logotyp-Ausnahmen. Wenn eine Website eine Logotyp-Ausnahme beansprucht, vergewissern Sie sich, dass es sich tatsächlich um ein Markenlogo handelt, bei dem das Design der Buchstabenformen untrennbar mit der Markenidentität verbunden ist, und nicht einfach um eine Überschrift in der Markenschrift.
- Testen Sie mit Browser-Zoom. Zoomen Sie den Browser auf 200 % und 400 % (mit Strg/Cmd + oder über die Browsereinstellungen). Beobachten Sie, ob der Text auf der Seite scharf bleibt. Bilder von Text werden unscharf oder pixelig; echter Text bleibt klar. Dieser Test prüft gleichzeitig auf Verstöße gegen 1.4.5 und verwandte Reflow-Aspekte (WCAG 1.4.4 und 1.4.10).
- Untersuchen Sie den SVG-Quellcode. Klicken Sie mit der rechten Maustaste auf ein SVG und wählen Sie „Quelltext anzeigen“ oder verwenden Sie die Browser-DevTools, um den SVG-DOM zu inspizieren. Vergewissern Sie sich, dass Textinhalt
<text>-Elemente verwendet und nicht<path>-Elemente, die Buchstabenumrisse nachzeichnen. Wenn der gesamte Text in Pfade umgewandelt wurde, hat das SVG dasselbe Problem wie ein Rasterbild von Text. - Testen Sie mit einem Screenreader, um die kumulative Auswirkung zu verstehen. Verwenden Sie NVDA mit Firefox, VoiceOver mit Safari auf macOS/iOS oder JAWS mit Chrome. Navigieren Sie zu Bildern von Text und prüfen Sie, ob das
alt-Attribut den Textinhalt korrekt wiedergibt. Während ein aussagekräftigesalt-Attribut WCAG 1.1.1 (Nicht-Text-Inhalt) erfüllt, behebt es den 1.4.5-Verstoß nicht – der Text bleibt nicht benutzeranpassbar. Dokumentieren Sie beide Probleme getrennt. - Wenden Sie ein benutzerdefiniertes User-Stylesheet oder eine Browser-Erweiterung an. Installieren Sie eine Browser-Erweiterung wie Stylus oder verwenden Sie die integrierte User-Stylesheet-Funktion von Firefox, um Schriftfamilien zu überschreiben und die Schriftgröße global zu erhöhen. Echter Text wird sich ändern; Bildtext nicht. Dies simuliert direkt, was Nutzer mit Lesebehinderungen erleben, wenn sie ihre bevorzugten Schriften anwenden.
Wie man es behebt
Dekorative Banner-Überschrift – Falsch
<!-- Fehlerhaft: Eine Marketing-Überschrift wird als JPEG gerendert,
um eine benutzerdefinierte Schrift zu erhalten -->
<div class='hero'>
<img src='summer-sale-heading.jpg' alt='Summer Sale — Up to 50% Off' />
</div>
Dekorative Banner-Überschrift – Korrekt
<!-- Behoben: Dieselbe benutzerdefinierte Schrift wird über @font-face
eingebunden und auf eine echte Überschrift angewendet.
Der Text ist jetzt auswählbar, skalierbar und benutzeranpassbar. -->
<style>
@font-face {
font-family: 'BrandDisplay';
src: url('/fonts/brand-display.woff2') format('woff2');
font-display: swap;
}
.hero-heading {
font-family: 'BrandDisplay', sans-serif;
font-size: clamp(2rem, 5vw, 4rem);
color: #c0392b;
text-shadow: 2px 2px 4px rgba(0,0,0,0.3);
}
</style>
<div class='hero'>
<h1 class='hero-heading'>Summer Sale — Up to 50% Off</h1>
</div>
SVG mit umgewandeltem Text – Falsch
<!-- Fehlerhaft: Text wurde beim SVG-Export in Pfade umgewandelt,
wodurch die Zeichen als Text unzugänglich und nicht skalierbar sind -->
<svg viewBox='0 0 400 80' xmlns='http://www.w3.org/2000/svg'>
<!-- Dutzende von <path>-Elementen, die die Buchstaben von 'Accsible' nachzeichnen -->
<path d='M10 60 L20 20 L30 60 ...' fill='#003087' />
</svg>
SVG mit umgewandeltem Text – Korrekt
<!-- Behoben: SVG verwendet ein echtes <text>-Element mit Webfont-Referenz.
Der Text ist jetzt indexierbar, auswählbar und skalierbar. -->
<svg viewBox='0 0 400 80' xmlns='http://www.w3.org/2000/svg'
role='img' aria-label='Accsible'>
<defs>
<style>
.svg-label {
font-family: 'BrandDisplay', sans-serif;
font-size: 48px;
fill: #003087;
}
</style>
</defs>
<text class='svg-label' x='10' y='60'>Accsible</text>
</svg>
CSS-Hintergrundbild mit Text-Overlay – Falsch
<!-- Fehlerhaft: Die Button-Beschriftung ist Teil des Hintergrundbildes
und kein echter Textknoten -->
<a href='/shop' class='cta-button'></a>
<style>
.cta-button {
display: block;
width: 200px;
height: 60px;
background: url('shop-now-button.png') no-repeat center;
background-size: cover;
}
</style>
CSS-Hintergrundbild mit Text-Overlay – Korrekt
<!-- Behoben: Der Button verwendet einen echten Textknoten, der mit CSS
gestaltet wird. Das Hintergrundbild ist rein dekorativ (Verlauf oder Textur). -->
<a href='/shop' class='cta-button'>Shop Now</a>
<style>
.cta-button {
display: inline-block;
padding: 1rem 2rem;
background: linear-gradient(135deg, #e74c3c, #c0392b);
color: #ffffff;
font-family: 'BrandDisplay', sans-serif;
font-size: 1.25rem;
font-weight: 700;
text-decoration: none;
border-radius: 4px;
}
</style>
Logotyp – Zulässige Ausnahme
<!-- Zulässig: Ein Logotyp, bei dem das spezifische Design der Buchstabenformen
die Markenidentität IST. Alt-Text gibt den Textinhalt korrekt wieder.
CSS kann die handgezeichneten Buchstabenformen nicht replizieren. -->
<a href='/' aria-label='Accsible — Home'>
<img src='accsible-logo.svg'
alt='Accsible'
width='160'
height='48' />
</a>
Häufige Fehler
- Verwendung eines JPEG oder PNG für Seitenüberschriften, weil im Design-Mockup eine Schrift verwendet wird, die nicht bei Google Fonts verfügbar ist – die richtige Lösung ist, die Schrift als WOFF2-Datei per
@font-faceselbst zu hosten, nicht die Überschrift in ein Bild einzubetten. - Export ganzer Hero-Sektionen als einzelnes flaches Bild aus Design-Tools wie Figma oder Photoshop, wodurch sämtlicher Text, Buttons und Beschriftungen in einer Rasterdatei eingebettet werden. Jedes Textelement muss ein eigener HTML-Knoten sein.
- Umwandeln von SVG-Text in Pfade beim Export, um Abhängigkeiten vom Schriftladen auf dem Server zu vermeiden. Dies beseitigt die Zugänglichkeit und Durchsuchbarkeit des Textes. Verwenden Sie stattdessen
<text>-Elemente mit einer CSS-Schriftreferenz. - Platzieren von Werbe- oder Rechtstext (wie Geschäftsbedingungen, Preise oder Teilnahmebedingungen) in einem Bild, um eine präzise Layoutkontrolle zu bewahren. Jeder Text, den Nutzer lesen müssen, muss echter HTML-Text sein.
- Die Logotyp-Ausnahme für jeden Marken-Text zu beanspruchen – die Ausnahme gilt nur für das eigentliche Logo, nicht für jede Überschrift oder Beschriftung in der Hausschrift. Eine Überschrift in Helvetica Neue ist kein Logotyp.
- Bereitstellen eines korrekten
alt-Attributs und die Annahme, damit sei der 1.4.5-Verstoß behoben – das ist er nicht. Alt-Text erfüllt WCAG 1.1.1 (Nicht-Text-Inhalt), macht den Bildtext aber nicht benutzeranpassbar, was die eigenständige Anforderung von 1.4.5 ist. - Verwendung von HTML5-
<canvas>-Elementen zur Darstellung von gestaltetem Text zu visuellen Zwecken ohne eine echte Textalternative im DOM bereitzustellen. Canvas-gerenderter Text hat alle dieselben Nachteile wie Bildtext. - Einbetten von Text in Open-Graph- oder Social-Sharing-Vorschaubilder und das Übersehen, dass diese Bilder ebenfalls auf der Seite erscheinen (zum Beispiel als Beitragsbild in einem Blogpost). Wenn das Beitragsbild dekorativen Kontext liefert, kann das akzeptabel sein – wenn es jedoch die primäre Überschrift des Artikels ist, ist es ein Verstoß.
- Ignorieren von E-Mail-Newsletter-Templates – auch wenn E-Mail-Clients außerhalb des WCAG-Browserscopes liegen, veröffentlichen viele Organisationen ihre Newsletter als Webseiten. Text in E-Mail-Headerbildern, die als Webinhalt eingebettet sind, löst weiterhin 1.4.5 aus.
- Die Annahme, dass hochauflösende Retina-Bilder das Problem lösen – ein 2×- oder 3×-Bild von Text ist schärfer als ein 1×-Bild, verstößt aber weiterhin gegen 1.4.5, weil der Text nicht anpassbar, nicht umfließbar und für Suchmaschinen und unterstützende Technologien unsichtbar bleibt.
Bezug zu den Barrierefreiheitsvorschriften der Türkei
Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Web- und Mobile-Barrierefreiheitsstandards für eine breite Palette von in der Türkei tätigen Einrichtungen fest. Die Verfügung verweist ausdrücklich auf WCAG 2.2 als normativen technischen Standard, und Konformität auf Level AA – einschließlich WCAG 1.4.5 – ist Voraussetzung für die Berechtigung zum Erişilebilirlik Logosu (Accessibility Logo), das vom Ministerium für Familie und Sozialdienste (Aile ve Sosyal Hizmetler Bakanlığı) vergeben wird. Dieses Logo dient als offizielles Zertifizierungszeichen, das anzeigt, dass ein digitales Produkt die in der Verfügung definierten Barrierefreiheitsanforderungen erfüllt.
Die von der Verfügung erfassten Einrichtungen umfassen einen breiten Querschnitt der digitalen Wirtschaft der Türkei. Öffentliche Institutionen und Regierungsbehörden auf allen Ebenen müssen die Vorgaben einhalten, ebenso wie Banken und Finanzinstitute, die von der BDDK (Banking Regulation and Supervision Agency) reguliert werden. Krankenhäuser und Gesundheitsdienstleister, sowohl öffentlich als auch privat, sind erfasst. Im Privatsektor fallen E-Commerce-Plattformen, Telekommunikationsanbieter mit 200,000 oder mehr Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen und Bildungseinrichtungen, die vom Bildungsministerium (MoNE / Milli Eğitim Bakanlığı) autorisiert sind, alle in den Geltungsbereich der Verfügung.
Für diese Organisationen hat WCAG 1.4.5 direkte und praktische Auswirkungen. Viele türkische E-Commerce- und institutionelle Websites verwenden Werbegrafiken, Banner mit benutzerdefinierten Schriften und Kampagnenüberschriften, die Text als Rasterbilder einbetten – eine gängige Praxis in Webdesign-Workflows, die in visuellen Design-Tools ihren Ursprung hat. Nach der Präsidialverfügung stellen solche Implementierungen eine Nichtkonformität auf Level AA dar und würden die Website von der Erlangung oder Aufrechterhaltung des Erişilebilirlik Logosu ausschließen. Banken, die Zinssatztabellen als Bilder anzeigen, Krankenhäuser, die Abteilungsnamen in PNG-Bannern aufführen, oder Telekommunikationsanbieter, die Promotion-Tarife als flache Bilddateien präsentieren, würden alle gegen dieses Kriterium verstoßen.
Organisationen, die konform sein wollen, sollten alle Bilder auf ihren Webpräsenzen auf eingebettete Textinhalte prüfen, zunächst die Umwandlung von Seiten mit hohem Traffic (Startseiten, Produktseiten, Service-Landingpages) priorisieren und einen Design-zu-Entwicklung-Workflow etablieren, der die Auslieferung von Textinhalten in Bilddateien untersagt. Investitionen in eine Webfont-Strategie mit @font-face im WOFF2-Format und geeigneten font-display-Werten ermöglichen es Designern, die von den Brand-Guidelines geforderte typografische Vielfalt zu erreichen und gleichzeitig vollständig mit WCAG 2.2 Level AA und der türkischen Barrierefreiheitsvorgabe von 2025 konform zu bleiben.
