WCAG 1.4.9: Bilder von Text (ohne Ausnahme)

WCAG 1.4.9 verlangt, dass Text mithilfe von tatsächlichem Text und nicht als Textbilder dargestellt wird, ohne Ausnahmen über rein dekorative Inhalte hinaus oder Fälle, in denen die spezifische visuelle Darstellung für die vermittelte Information wesentlich ist. Dieses Kriterium stellt sicher, dass alle Nutzer die Textdarstellung an ihre individuellen Bedürfnisse anpassen können.

Was diese Regel bedeutet

WCAG 1.4.9 — Bilder von Text (keine Ausnahme) ist ein Kriterium der Stufe AAA, das die Anforderungen von WCAG 1.4.5 (Bilder von Text, Stufe AA) zu ihrer logischen Konsequenz führt. Während 1.4.5 Bilder von Text zulässt, wenn das Bild visuell anpassbar ist oder wenn eine bestimmte visuelle Darstellung wesentlich ist, beseitigt 1.4.9 nahezu alle diese Ausnahmen. Nach diesem Kriterium muss Text mit tatsächlichem Text gerendert werden – echten Zeichen im DOM – und nicht als raster- oder vektorbasierte Bilder, die Text enthalten.

Die einzige zulässige Ausnahme nach 1.4.9 ist Text, der rein dekorativ ist (absolut keinen Informationswert trägt) oder Text, der Teil eines Logos oder Markennamens ist, bei dem die spezifische visuelle Gestaltung untrennbar mit der vermittelten Identität verbunden ist. In der Praxis bedeutet dies, dass Produkt-Screenshots mit Text, Banner-Grafiken mit Werbetext, Infografiken mit beschrifteten Daten, Zertifikatsbilder, Social-Media-ähnliche Zitatkarten und gescannte Dokumente, die im Web angezeigt werden, alle durch echten gerenderten Text ersetzt oder zumindest durch solchen ergänzt werden müssen.

Ein Bestehen nach 1.4.9 liegt vor, wenn jedes sinnvolle, für die Nutzer sichtbare Textstück durch die Text-Engine des Browsers gerendert wird – sei es durch HTML-Textknoten, CSS-generierte Inhalte, wo angemessen, oder SVG-<text>-Elemente –, sodass der User Agent den Text neu umbrechen, in der Größe ändern, neu einfärben und den Abstand anpassen kann. Ein Nichtbestehen liegt vor, wenn ein <img>, <canvas>, ein CSS-Hintergrundbild, ein SVG-<image>, ein eingebettetes PDF oder eine andere Nicht-Text-Ressource verwendet wird, um bedeutungstragenden Text anzuzeigen – unabhängig davon, ob ein alt-Attribut bereitgestellt wird. Beachten Sie, dass ein gut geschriebenes alt-Attribut zwar 1.1.1 (Nicht-Text-Inhalt) adressiert, aber 1.4.9 nicht erfüllt, da der Alternativtext nicht visuell gerendert wird und das ursprüngliche Bild sehenden Nutzern weiterhin die Möglichkeit nimmt, die visuelle Darstellung des Textes anzupassen.

Das Kriterium betrifft die folgenden gängigen HTML-Muster: <img>-Elemente, deren Quelldateien Text enthalten; CSS-background-image-Eigenschaften, die auf Bilder mit eingebettetem Text verweisen; <canvas>-Elemente, auf die programmatisch Text gezeichnet wurde; Inline-SVG-Elemente, die <image> statt <text> verwenden; und eingebettete Inhalte von Drittanbietern wie iframes mit gerenderten Bildinhalten. Selbst technisch skalierbare Formate wie SVG geraten unter Beobachtung, wenn Text als Pfad oder Bild statt als SVG-<text>-Knoten eingebettet wird.

Warum das wichtig ist

Laut der Weltgesundheitsorganisation haben weltweit etwa 2,2 Milliarden Menschen irgendeine Form von Sehbeeinträchtigung. Eine bedeutende Teilgruppe dieser Personen – darunter Menschen mit Sehrest, Farbsehschwächen, Dyslexie und anderen Lesebehinderungen – ist auf Textanpassungswerkzeuge auf Browser- oder Betriebssystemebene angewiesen, um Inhalte lesbar zu machen. Zu diesen Werkzeugen gehören Zoomfunktionen, Schriftart-Ersetzung, vergrößerter Zeichen- und Wortabstand, Hochkontrast- oder benutzerdefinierte Farbschemata sowie Sprachausgabe-Engines, die auf gerendertem DOM-Text arbeiten. Wenn Text in ein Bild eingebettet ist, werden all diese Anpassungen für diesen Inhalt vollständig unzugänglich.

Stellen Sie sich eine Nutzerin mit Sehrest vor, die ihren Browser so eingestellt hat, dass Text in einer großen serifenlosen Schrift mit kontrastreichem Gelb-auf-Schwarz-Farbschema gerendert wird. Wenn sie auf ein Werbebanner stößt, in dem „Summer Sale — 50% Off“ in ein JPEG „eingebacken“ ist, kann der Browser diesen Text weder neu einfärben noch neu umbrechen. Das Bild kann sich mit dem Seitenzoom vergrößern, wird aber schnell pixelig und schwerer lesbar statt klarer. Würde dieselbe Botschaft als echter HTML-Text gerendert und mit CSS gestaltet, würden die Browser-Einstellungen der Nutzerin automatisch angewendet, und der Inhalt bliebe scharf, anpassbar und zugänglich.

Nutzerinnen und Nutzer mit Dyslexie installieren häufig Browser-Erweiterungen oder verwenden benutzerdefinierte Stylesheets, die Schriftarten auf dyslexiefreundliche Typografien wie OpenDyslexic umstellen und Zeichen- und Wortabstände vergrößern, um visuelle Überfrachtung zu reduzieren. Bilder von Text umgehen diese Anpassungen vollständig. Ein Call-to-Action-Button, der als Bild statt als gestaltetes HTML-Element gerendert wird, ist für diese Anpassungen faktisch unsichtbar und kann kritische interaktive Elemente vor Personen verbergen, die auf personalisierte Darstellung angewiesen sind.

Motorisch beeinträchtigte Nutzerinnen und Nutzer, die auf Schaltersteuerung oder Blickverfolgungssoftware angewiesen sind, verwenden Zoomwerkzeuge möglicherweise sehr intensiv, um präzise Ziele zu treffen. Verschwommene, niedrig aufgelöste Textbilder bei hohen Zoomstufen erschweren das Zielen zusätzlich. Screenreader-Nutzerinnen und -Nutzer, die noch über etwas Restsehvermögen verfügen, aber dennoch einen Screenreader zum Verständnis einsetzen, können außerdem feststellen, dass Bilder von Text je nach Sorgfalt der Autorin beim Verfassen eines vollständigen alt-Attributs uneinheitlich angesagt werden – und selbst ein perfekter alt-Text stellt die visuelle Darstellung, die sie benötigen, nicht wieder her.

Über den Zugang für Menschen mit Behinderungen hinaus bringt die Verwendung von echtem Text statt Bildern von Text bedeutende SEO-Vorteile. Suchmaschinen-Crawler indexieren DOM-Text wesentlich zuverlässiger, als sie Bildinhalte interpretieren können. Das bedeutet, dass in Bildern eingebettete Werbeüberschriften, Produktnamen und Kategorienamen möglicherweise nur wenig oder gar kein Gewicht für das Suchranking erhalten. Echter Text ist für die meisten typografischen Anwendungsfälle außerdem dateigrößenmäßig leichter, verbessert die Core-Web-Vitals-Werte und reduziert den Bandbreitenverbrauch für Nutzerinnen und Nutzer mit mobilen Datenverbindungen – ein besonders wichtiger Aspekt in Märkten, in denen die mobile Internetdurchdringung hoch ist und Datenkosten weiterhin eine Rolle spielen.

Wie man testet

Führen Sie einen automatisierten Scan als ersten Durchlauf aus. Öffnen Sie axe DevTools, die Deque-Browsererweiterung oder Lighthouse in den Chrome DevTools und führen Sie ein Audit der gesamten Seite durch. Überprüfen Sie alle markierten bildbezogenen Probleme. Obwohl keine automatisierte Regel 1.4.9 direkt abdeckt, werden in diesem Schritt alle <img>-Elemente und CSS-Hintergrundbilder für eine anschließende manuelle Überprüfung sichtbar gemacht. Exportieren Sie die Ergebnisse und notieren Sie jedes Bild, das ein nicht leeres, satzähnliches alt-Attribut trägt oder das von axe unter image-alt markiert wird.
Prüfen Sie alle Bilder und Hintergrundgrafiken visuell. Scrollen Sie durch die Seite und untersuchen Sie jedes Bild, jeden CSS-Hintergrund, jedes Canvas-Element und jede SVG-Grafik. Fragen Sie: Enthält dieses Bild Text? Wenn ja, ist dieser Text rein dekorativ (fügt keine Information hinzu und könnte ohne Verlust entfernt werden)? Handelt es sich um ein Logotyp, bei dem der spezifische Schriftstil untrennbar mit der Markenidentität verbunden ist? Wenn keine der beiden Ausnahmen zutrifft, liegt bei dem Bild ein Verstoß gegen 1.4.9 vor.
Deaktivieren Sie Bilder im Browser. Gehen Sie in Firefox zu about:config und setzen Sie permissions.default.image auf 2, oder verwenden Sie eine Erweiterung wie „Disable Images“. Laden Sie die Seite neu. Jede Textinformation, die verschwindet und nicht durch sichtbaren DOM-Text ersetzt wird (nicht nur durch ein alt-Attribut, das von einem Screenreader angesagt wird), stellt einen Verstoß gegen 1.4.9 dar. Aktivieren Sie die Bilder nach dem Testen wieder.
Wenden Sie ein benutzerdefiniertes User-Stylesheet an. Legen Sie in Firefox eine Datei im Profilordner unter chrome/userContent.css an und fügen Sie eine Regel wie * { font-family: OpenDyslexic, sans-serif !important; color: yellow !important; background-color: black !important; } hinzu. Laden Sie die Seite neu. Text, der als echter HTML-Text gerendert wird, übernimmt diese Stile; in Bilder eingebetteter Text ändert sich nicht. Jeder Textinhalt, der unter diesen erzwungenen Stilen visuell unverändert und unlesbar bleibt, ist ein Fehler.
Testen Sie mit NVDA und Firefox. Navigieren Sie mit dem Browse-Modus von NVDA durch die Seite. Notieren Sie für jedes Bild, was NVDA ansagt. Wenn NVDA ein alt-Attribut vorliest, das umfangreichen Textinhalt enthält, vergleichen Sie diesen Inhalt mit dem, was visuell im Bild dargestellt wird. Das Vorhandensein bedeutungstragenden Textinhalts in einem alt-Attribut ist ein starkes Indiz dafür, dass das Bild Text enthält – und bestätigt einen Verstoß gegen 1.4.9, selbst wenn 1.1.1 technisch erfüllt ist.
Testen Sie mit VoiceOver und Safari auf macOS. Verwenden Sie VO + Pfeil nach rechts, um sich durch die Inhalte zu bewegen. Achten Sie auf Bildbeschreibungen, die vollständige Sätze, Überschriften oder Werbetexte wiedergeben. Gleichen Sie dies mit der visuellen Prüfung ab, um zu bestätigen, dass die Quelle ein Bild und kein echter Text ist.
Zoomen Sie auf 400%. WCAG 1.4.4 und 1.4.10 verlangen, dass Text bei hohen Zoomstufen lesbar bleibt. Bilder von Text werden beim Browserzoom pixelig; echter Text, der von der Browser-Engine gerendert wird, bleibt scharf. Bei 400% Zoom ist jeder Text, der verschwommen oder pixelig erscheint, wahrscheinlich ein Bild von Text und sollte als möglicher Verstoß gegen 1.4.9 untersucht werden.

Wie man es behebt

Werbebanner mit eingebettetem Text — Falsch

<!-- A marketing banner where the headline and CTA are baked into the image.
     Even with alt text, users cannot customize the text rendering. -->
<a href='/sale'>
  <img src='/images/summer-sale-banner.jpg'
       alt='Summer Sale — Up to 50% off all products. Shop Now.'
       width='1200' height='400'>
</a>

Werbebanner mit eingebettetem Text — Richtig

<!-- The banner uses a real background image for visual decoration,
     while all text is rendered as real HTML so users can resize,
     recolor, and reflow it independently. -->
<a href='/sale' class='sale-banner'>
  <!-- Background image set via CSS: .sale-banner { background-image: url(/images/summer-bg.jpg); } -->
  <h2 class='sale-banner__headline'>Summer Sale</h2>
  <p class='sale-banner__offer'>Up to 50% off all products</p>
  <span class='sale-banner__cta'>Shop Now</span>
</a>

Infografik mit beschrifteten Datenpunkten — Falsch

<!-- An infographic where category labels and percentages are drawn
     into the PNG. Screen reader users hear the alt; sighted low-vision
     users cannot enlarge or recolor the labels. -->
<img src='/images/market-share-2024.png'
     alt='Market share 2024: Product A 42%, Product B 31%, Product C 27%'
     width='800' height='600'>

Infografik mit beschrifteten Datenpunkten — Richtig

<!-- An accessible SVG chart where all labels are SVG <text> nodes.
     Users can zoom, reflow, and apply high-contrast themes to the text.
     An adjacent <table> provides the same data in tabular form. -->
<figure>
  <svg viewBox='0 0 800 400' role='img'
       aria-labelledby='chart-title chart-desc'>
    <title id='chart-title'>Market Share 2024</title>
    <desc id='chart-desc'>Pie chart: Product A 42%, Product B 31%, Product C 27%</desc>
    <!-- chart paths -->
    <text x='200' y='150' class='chart-label'>Product A — 42%</text>
    <text x='450' y='200' class='chart-label'>Product B — 31%</text>
    <text x='350' y='320' class='chart-label'>Product C — 27%</text>
  </svg>
  <figcaption>
    <details>
      <summary>View data as table</summary>
      <table>
        <caption>Market Share 2024</caption>
        <thead><tr><th>Product</th><th>Share</th></tr></thead>
        <tbody>
          <tr><td>Product A</td><td>42%</td></tr>
          <tr><td>Product B</td><td>31%</td></tr>
          <tr><td>Product C</td><td>27%</td></tr>
        </tbody>
      </table>
    </details>
  </figcaption>
</figure>

CSS-Hintergrundbild mit textlastigem Header — Falsch

<!-- The page title is set as a CSS background image rather than real text.
     This is a common design pattern from the early 2000s image-replacement era
     that should not appear in modern codebases. -->
<h1 class='logo-header'></h1>
<!-- CSS: .logo-header {
       background: url('/images/page-title-about-us.png') no-repeat;
       width: 400px; height: 80px; display: block;
       text-indent: -9999px;
     } -->

CSS-Hintergrundbild mit textlastigem Header — Richtig

<!-- Real text is rendered by the browser. Custom web fonts reproduce
     the desired typographic style without sacrificing adaptability.
     The background image, if needed at all, is purely decorative texture. -->
<h1 class='page-title'>About Us</h1>
<!-- CSS: .page-title {
       font-family: 'BrandTypeface', serif;
       font-size: 3rem;
       color: #1a1a2e;
       letter-spacing: 0.05em;
     } -->

Häufige Fehler

Die Annahme, ein vollständiges alt-Attribut erfülle 1.4.9. Ein ausführlicher Textalternativinhalt im alt-Attribut erfüllt WCAG 1.1.1, bewirkt aber für 1.4.9 nichts. Das Kriterium bezieht sich ausdrücklich darauf, dass die visuelle Darstellung von Text anpassbar zugänglich ist, nicht auf programmatische Entsprechungen für Screenreader.
Verwendung von CSS-Techniken zur Bildersetzung (text-indent: -9999px oder clip-Methoden) auf <h1>- bis <h6>-Elementen. Diese veralteten Techniken blenden echten Text visuell aus und ersetzen ihn durch ein Hintergrundbild, sodass sehende Nutzerinnen mit Sehrest nur das Bild erhalten, während Screenreader-Nutzerinnen nur den versteckten Text erhalten – ein Missverhältnis, das beiden Gruppen auf unterschiedliche Weise schadet.
Export von Webtypografie als PNG oder JPEG, weil eine benutzerdefinierte Schriftart nicht als Webfont verfügbar ist. Wenn eine lizenzierte Schriftart rechtlich nicht als Webfont bereitgestellt werden darf, besteht die richtige Lösung darin, Webfont-Rechte zu verhandeln oder eine alternative Schriftart zu wählen – nicht darin, Text in Bilder zu rastern.
Die Annahme, SVG-Dateien seien per se zugänglich. Ein SVG, das Text als <path>-Elemente einbettet (eine häufige Ausgabe von Grafikwerkzeugen wie der „Text in Pfade umwandeln“-Option in Illustrator), ist genauso unzugänglich wie ein PNG. Das SVG muss <text>-Elemente verwenden, um 1.4.9 zu erfüllen.
Einbetten von Text in <canvas>-Elemente ohne Fallback mit echtem Text. Canvas-Inhalte werden auf Pixelebene gerastert. Jeder Text, der über ctx.fillText() gezeichnet wird, ist nicht Teil des DOM und kann von User Agents nicht angepasst werden. Ein Overlay oder eine Alternative mit echtem Text ist erforderlich.
Belassen von gescannten Dokumenten (als Bilder gerenderte PDFs) ohne OCR-basierte echte Textschichten. Gescannt vorliegende Dokumente, die in <img>-Tags oder als reine Bild-PDFs präsentiert werden, verstoßen gegen 1.4.9. Es ist erforderlich, OCR auszuführen und eine auswählbare Textschicht einzubetten oder das Dokument in korrekt ausgezeichnetes HTML zu konvertieren.
Verwendung von Bildern von Text für dynamische Daten wie Preise, Lagerbestände oder nutzergenerierte Inhalte. Immer wenn ein Server ein Bild erzeugt, das Textdaten enthält, werden diese Daten im Bildformat „eingeschlossen“. Preise in Produktlisten, Platzverfügbarkeit auf Buchungsplattformen und Live-Sportergebnisse müssen als echter Text gerendert werden, damit Nutzerinnen und Nutzer sie vergrößern und neu einfärben können.
Übersehen von E-Mail-Signaturbildern. Marketingteams erstellen Signaturblöcke häufig als Bilder, um das visuelle Branding zu bewahren. Wenn diese E-Mails archiviert und von Websites aus verlinkt werden, werden die Signaturbilder zu Webinhalten, die 1.4.9 unterliegen.
Ignorieren von Inhalten in Widgets von Drittanbietern. Chat-Widgets, Social-Proof-Badges und Bewertungs-Karussells von Drittanbietern können Bilder von Text in die Seite einfügen. Website-Betreiber bleiben für die Barrierefreiheit aller Inhalte auf ihren Seiten verantwortlich; wenn ein Anbieter keine textbasierte Darstellung liefern kann, sollte ein anderer Anbieter gewählt werden.
Verwechslung von Logotyp-Ausnahmen mit allgemeinen Branding-Ausnahmen. Die Logotyp-Ausnahme umfasst nur das Logo oder Wortbildzeichen selbst – den stilisierten Markennamen. Sie erstreckt sich nicht auf Slogans, Navigationsbeschriftungen oder anderen Text, der zusammen mit dem Logo im selben Bild erscheint.

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 Web-Barrierefreiheitsverpflichtungen für eine breite Palette von Organisationen fest, die in der Türkei tätig sind. Die Verfügung verlangt von den erfassten Stellen, mindestens WCAG 2.1 Stufe AA einzuhalten. Zu den ausdrücklich erfassten Stellen gehören öffentliche Institutionen und Regierungsbehörden, E-Commerce-Plattformen, Banken und Finanzinstitute, Krankenhäuser und private Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnentinnen und Abonnenten, Reisebüros, private Transportunternehmen und private Schulen, die vom Ministerium für Nationale Bildung autorisiert sind.

WCAG 1.4.9 ist ein Kriterium der Stufe AAA und liegt damit über dem durch die Präsidialverfügung 2025/10 festgelegten verbindlichen Mindeststandard. Erfasste Stellen sind rechtlich nicht verpflichtet, 1.4.9 einzuhalten, um die Basisanforderungen der Verfügung zu erfüllen. Die Erreichung der Stufe AAA bei anwendbaren Kriterien zeigt jedoch ein erstklassiges Engagement für Inklusion und erweitert die Zielgruppe, die den Dienst effektiv nutzen kann, erheblich.

Mehrere durch die Verfügung erfasste Sektoren haben besonders starke Anreize, die Einhaltung von 1.4.9 freiwillig anzustreben. E-Commerce-Plattformen verwenden häufig Werbebanner, Angebotsgrafiken und Produktkategorie-Header, die als Bilder gerendert werden – allesamt typische Muster für Verstöße gegen 1.4.9. Für Nutzerinnen und Nutzer mit Sehrest oder Dyslexie, die auf Textanpassung angewiesen sind, um Kaufentscheidungen zu treffen, führen diese Verstöße direkt zu verlorenen Conversions und potenzieller rechtlicher Haftung im Rahmen der weiter gefassten verbraucherschutz- und antidiskriminierungsrechtlichen Regelungen der Türkei. Banken und Finanzinstitute präsentieren in ähnlicher Weise Kreditzinsen, Kontoübersichten und Gebührenverzeichnisse; wenn Informationen dieser Art in Bildern eingebettet sind, können Kundinnen und Kunden mit Sehrest die Darstellung nicht anpassen, um sie sicher zu lesen, was sowohl im Rahmen der Verfügung als auch der verbraucherschutzrechtlichen Vorschriften für Finanzdienstleistungen Bedenken aufwirft. Krankenhäuser und Gesundheitsdienstleister, die Dosierungsanweisungen, Termindetails oder Patienteninformationen in Bildform anzeigen, schaffen Patientensicherheitsrisiken für Nutzerinnen und Nutzer, die die Textdarstellung nicht anpassen können.

Organisationen, die ihre digitalen Angebote gegenüber zukünftigen regulatorischen Entwicklungen absichern möchten – oder solche, die öffentliche Ausschreibungen anstreben, die nachweisliche Barrierefreiheitsführerschaft verlangen –, sind gut beraten, Verstöße gegen 1.4.9 im Rahmen eines umfassenden Barrierefreiheitsprogramms zu prüfen und zu beheben. Das Overlay-SDK von Accsible kann bei der Laufzeitanpassung von Text für einige Legacy-Szenarien mit Bildern von Text unterstützen, aber eine dauerhafte Behebung auf Code-Ebene – das Ersetzen von Bildern von Text durch echten HTML-Text, der über CSS und Webfonts gestaltet wird – bleibt die robusteste und dauerhafteste Lösung für langfristige Konformität.