Zum Inhalt springen
BFSG-Compliance seit 2025
E-Mail-Marketing

Barrierefreie Newsletter: E-Mail-Marketing nach BFSG

Barrierefreie Newsletter und Transaktionsmails nach BFSG und WCAG 2.1: lang-Attribut, Alt-Texte, Kontrast, echter Text und Dark Mode praktisch umsetzen.

13 Min. Lesezeit E-Mail-MarketingNewsletterBFSGTransaktionsmailsWCAG 2.1

E-Mail ist der Kanal, den Marketing- und Content-Teams am unmittelbarsten selbst steuern: Newsletter, Produktankündigungen, Bestellbestätigungen, Versandhinweise, Passwort-Mails. Genau dieses Medium bleibt in der Debatte um Barrierefreiheit meist außen vor, obwohl es täglich Millionen Postfächer erreicht. Der aktuelle Accessibility Report des Email Markup Consortium hat 376.348 (Email Markup Consortium, 2026) HTML-E-Mails aus einem Jahr untersucht und in 99,88 Prozent (Email Markup Consortium, 2026) davon ernste oder kritische Barrieren gefunden. Für Transaktionsmails, die Teil eines elektronischen Bestellvorgangs sind, ist das kein kosmetisches Problem, sondern eine Frage der BFSG-Anforderungen. Dieser Beitrag zeigt, wie Newsletter und automatisierte Mails nach WCAG 2.1 zugänglich werden, vom lang-Attribut über Alt-Texte bis zur Dark-Mode-Robustheit, und wo ein strukturiertes WCAG-Audit die Lücken sichtbar macht.

Barrierefreie E-Mail: worauf es ankommtBetreff: Ihre Bestellung ist unterwegsVon: Beispiel-Shop • an: kundin@example.comlang=deBestellbestätigungEchter Text statt Bild: vorlesbar, skalierbarund auch bei blockierten Bildern sichtbar.alt: Sneaker, seitlichrole=presentationSendung verfolgenKontrast 4,5:1geprüftSchriftgröße rund 14–16 px, per Zoom skalierbarFarben robust in hellem und dunklem Moduslang-AttributWCAG 3.1.162% ohne (EMC)Alt-TextWCAG 1.1.148% ohne (EMC)Kontrast 4,5:1WCAG 1.4.3Text auf HintergrundLayout-Tabellerole=presentation84% ohne (EMC)Schriftgrößeskalierbarrund 14–16 pxDark Moderobustin beiden Modi lesbar99,88%der HTML-E-Mails miternsten Barrieren (EMC)47,88%der Bilder ohneAlt-Text (EMC)So besteht die E-Mail den TestEchter Text, ausgezeichnete Sprache, geprüfter Kontrast, robust im Dark Mode

Wann E-Mails unter das BFSG fallen

Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025 (BFSG) und setzt den European Accessibility Act (Richtlinie EU 2019/882) in deutsches Recht um. Es verlangt, dass bestimmte digitale Dienstleistungen barrierefrei angeboten werden, und verweist für die technische Umsetzung auf die harmonisierte Norm EN 301 549, die ihrerseits auf die Erfolgskriterien der WCAG zeigt. Warum diese Norm EN 301 549 den Prüfmaßstab hinter dem BFSG bildet, ordnen wir in einem eigenen Beitrag ein. Für E-Mails ist die entscheidende Frage, ob eine Nachricht zur Dienstleistung selbst gehört oder reine Werbung ist.

Eine Bestellbestätigung, eine Rechnung, ein Versandhinweis oder eine Passwort-Mail ist untrennbar mit dem elektronischen Geschäftsverkehr verbunden: Ohne sie lässt sich der Kauf nicht abschließen oder das Konto nicht nutzen. Solche Transaktionsmails sind damit Teil der Benutzerschnittstelle der Dienstleistung und sollten denselben Maßstab erfüllen wie der Shop selbst. Ein reiner Werbe-Newsletter, der nur auf Angebote aufmerksam macht, ist dagegen nicht ohne Weiteres eine eigenständige Dienstleistung im Sinne des Gesetzes. Die konkrete Einordnung hängt vom Einzelfall ab und ersetzt keine Rechtsberatung.

Der Prüfmaßstab liegt fest

Fällt eine E-Mail in den Anwendungsbereich, wird sie an denselben messbaren Kriterien gemessen wie jede Web-Oberfläche: verständliche Sprache, Textalternativen für Bilder, ausreichender Kontrast und eine sinnvolle Struktur. EN 301 549 verweist für digitale Inhalte auf die WCAG, sodass ein Postfach kein rechtsfreier Raum ist, sondern demselben Regelwerk folgt wie die Website dahinter.

Transaktionsmail oder Werbe-Newsletter

Die Trennlinie zwischen Pflicht und guter Praxis verläuft nicht entlang der Absenderadresse, sondern entlang des Zwecks. Wer beide Kategorien sauber unterscheidet, kann den Aufwand priorisieren, ohne den Anspruch an Zugänglichkeit fallen zu lassen. Die folgende Übersicht ordnet die gängigen E-Mail-Typen ein.

E-Mail-TypTypische BeispieleEinordnungEmpfehlung
TransaktionsmailBestellbestätigung, Rechnung, Versand, Passwort-ResetTeil der elektronischen DienstleistungBarrierefrei nach WCAG umsetzen
Service-MailTerminerinnerung, Statusupdate, KontobenachrichtigungEng mit der Dienstleistung verbundenWie Transaktionsmails behandeln
Werbe-NewsletterAngebote, Rabatte, Content-DigestIn der Regel keine eigene DienstleistungZugänglich als Standard und Reichweitenvorteil
MischformNewsletter mit Rechnungslink oder KontofunktionEinordnung im EinzelfallIm Zweifel den strengeren Maßstab anlegen

Für Werbe-Newsletter greift zudem der Grundgedanke des Allgemeinen Gleichbehandlungsgesetzes (AGG): Wer einen Teil seines Publikums systematisch ausschließt, riskiert nicht nur Reichweite, sondern auch eine Benachteiligung, die dem Gleichbehandlungsgedanken widerspricht. Barrierefreie Newsletter sind daher auch dort sinnvoll, wo keine unmittelbare BFSG-Pflicht besteht, als Standard, der niemanden aussperrt und die eigene Reichweite vergrößert.

Einordnung ersetzt keine Rechtsberatung

Die Zuordnung einer konkreten E-Mail hängt von Anbieter, Branche und Vertragskontext ab. Dieser Beitrag ordnet die Praxis ein, trifft aber keine verbindliche rechtliche Bewertung. Für die eigene Situation lohnt der Blick auf die genauen Voraussetzungen und im Zweifel eine juristische Prüfung.

Der Zustand barrierefreier E-Mails in Zahlen

Die Datenlage ist eindeutig und ernüchternd. Von den 376.348 (Email Markup Consortium, 2026) im Berichtszeitraum geprüften HTML-E-Mails bestanden nur acht alle automatisierten Tests. Am häufigsten fehlten grundlegende Bausteine, die im Web längst Standard sind. Sechs Befunde stechen heraus und lassen sich direkt auf konkrete WCAG-Kriterien zurückführen.

Sprache nicht ausgezeichnet

In 62,16 Prozent (Email Markup Consortium, 2026) der E-Mails fehlt das lang-Attribut im html-Tag, sodass Screenreader die falsche Aussprache wählen (WCAG 3.1.1).

Bilder ohne Alternative

47,88 Prozent (Email Markup Consortium, 2026) der Bilder tragen keinen Alternativtext und bleiben für Screenreader und bei blockierten Bildern leer (WCAG 1.1.1).

Tabellen ohne Rolle

83,78 Prozent (Email Markup Consortium, 2026) der Layout-Tabellen sind nicht als reines Layout gekennzeichnet, was die Vorlesereihenfolge stört (WCAG 1.3.1).

Nichtssagende Links

71,23 Prozent (Email Markup Consortium, 2026) der E-Mails enthalten Links ohne erkennbaren Text, weitere 15,83 Prozent (Email Markup Consortium, 2026) nur unklare Beschriftungen (WCAG 2.4.4).

Text als Bild

Ganze Kampagnen werden als eine einzige Grafik verschickt. Sind Bilder blockiert oder wird vorgelesen, bleibt die Botschaft unsichtbar (WCAG 1.4.5).

Zu schwacher Kontrast

Zarte Grautöne auf Weiß und blasse Buttons unterschreiten oft den geforderten Kontrast von 4,5:1 für normalen Text (WCAG 1.4.3).

Automatische Tests sind nur der Anfang

Selbst die wenigen E-Mails, die alle automatisierten Prüfungen bestanden, fielen bei der manuellen Kontrolle durch fehlende Textgrößen und Alt-Text-Mängel auf (Email Markup Consortium, 2026). Automatisierte Prüfungen finden nur einen Teil der Barrieren; die Bewertung mit Tastatur, Screenreader und im echten Postfach bleibt unverzichtbar.

Sprache auszeichnen: das lang-Attribut

Ein Screenreader entscheidet anhand der ausgezeichneten Sprache, welche Aussprache-Engine er verwendet. Fehlt die Angabe, liest eine englische Stimme womöglich einen deutschen Newsletter vor, und das Ergebnis ist kaum verständlich. Erfolgskriterium 3.1.1 verlangt deshalb, dass die Hauptsprache des Dokuments programmatisch bestimmbar ist, Kriterium 3.1.2 ergänzt einzelne Sprachwechsel im Text. In der Praxis heißt das: Das html-Element der E-Mail bekommt ein lang-Attribut, und fremdsprachige Passagen werden gesondert ausgezeichnet.

newsletter-sprache.html
<!-- Hauptsprache der E-Mail auszeichnen -->
<html lang="de" dir="ltr">
  <body>
    <h1>Ihre Bestellung ist unterwegs</h1>
    <p>Vielen Dank für Ihren Einkauf.</p>
    <!-- Sprachwechsel gesondert markieren -->
    <p>Unser Motto: <span lang="en">stay curious</span>.</p>
  </body>
</html>

Kleiner Zusatz, große Wirkung

Das lang-Attribut kostet ein Attribut pro Vorlage und ist trotzdem einer der am häufigsten übersehenen Punkte: In 62,16 Prozent (Email Markup Consortium, 2026) der E-Mails fehlt es im html-Tag, und in noch mehr Fällen ist im Textkörper keine Sprache gesetzt. Wer es einmal in die Master-Vorlage einträgt, löst das Problem für jede künftige Sendung.

Echter Text statt Bild-E-Mail

Ein verbreiteter Fehler ist die Bild-E-Mail: Die gesamte Nachricht, also Überschrift, Fließtext und Button, wird in einer einzigen Grafik gestaltet und verschickt. Das sieht in der Designvorschau perfekt aus, scheitert aber an der Realität der Postfächer. Viele E-Mail-Programme blockieren externe Bilder standardmäßig; dann bleibt statt der Botschaft eine leere Fläche. Screenreader können ein Bild ohnehin nicht vorlesen, und wer den Text vergrößert, erhält nur einen unscharfen Pixelbrei. Erfolgskriterium 1.4.5 rät ausdrücklich von Text als Bild ab, wo echter Text möglich ist.

  • Echter Text ist vorlesbar: Nur maschinenlesbarer Text erreicht Screenreader und Sprachausgabe (WCAG 1.1.1, 1.4.5).
  • Echter Text skaliert: Beim Zoomen bleibt er scharf, während Text in Bildern verpixelt und schwer lesbar wird.
  • Echter Text übersteht die Bildblockade: Ist das Laden von Bildern deaktiviert, bleibt die Kernbotschaft trotzdem sichtbar.
  • Alt-Texte für inhaltstragende Bilder: Produktfotos und Grafiken mit Aussage brauchen eine treffende Beschreibung; rein dekorative Bilder erhalten ein leeres alt-Attribut.
  • Sinnvoller Vorschautext: Der vorangestellte Preheader ersetzt keinen Alt-Text, hilft aber allen, die Relevanz einer Mail schnell einzuschätzen.

Bilder ergänzen den Text, sie ersetzen ihn nicht

Fast die Hälfte aller Bilder in E-Mails trägt keinen Alternativtext, genau 47,88 Prozent (Email Markup Consortium, 2026). Dabei ist ein guter Alt-Text schnell geschrieben: Er beschreibt, was auf dem Bild inhaltlich zählt, nicht jedes Detail. Wie treffende Alternativtexte entstehen, zeigt unser Beitrag zu barrierefreien Bildern und Alt-Texten.

Struktur: Layout-Tabellen und Leserichtung

HTML-E-Mails werden bis heute mit verschachtelten Tabellen aufgebaut, weil viele Mailprogramme moderne CSS-Layouts nicht zuverlässig darstellen. Das ist technisch legitim, wird aber zur Barriere, wenn eine reine Layout-Tabelle wie eine Datentabelle behandelt wird. Ein Screenreader kündigt dann Zeilen und Spalten an, die inhaltlich keine Bedeutung haben, und die Vorlesereihenfolge zerfällt. Abhilfe schafft die Kennzeichnung role=presentation (oder role=none), die dem Hilfsmittel signalisiert: Diese Tabelle dient nur der Anordnung.

AspektLayout-TabelleEchte Datentabelle
ZweckOrdnet Blöcke visuell anStellt Zeilen und Spalten in Beziehung
Rollerole=presentation, damit stummAls Tabelle mit Kopfzellen angesagt
KopfzellenKeine th-Elemente nötigth mit scope für Zeile und Spalte
ScreenreaderLiest den Inhalt der Reihe nachNennt zu jeder Zelle die Überschrift

Ebenso wichtig ist die Reihenfolge im Quelltext, denn Screenreader lesen den Code, nicht das visuelle Layout. Was per Tabelle nebeneinander steht, wird nacheinander vorgelesen; stimmt die Quelltextreihenfolge nicht mit der logischen Lesefolge überein, entsteht ein Durcheinander. Ein einspaltiges, lineares Layout ist deshalb nicht nur mobilfreundlich, sondern auch die robusteste Grundlage für eine korrekte Vorlesereihenfolge. Wo eine E-Mail echte Daten transportiert, etwa eine Rechnungsaufstellung, gelten die Regeln für barrierefreie Datentabellen und komplexe Inhalte.

Layout-Tabelle ist nicht gleich Datentabelle

83,78 Prozent (Email Markup Consortium, 2026) der Layout-Tabellen in E-Mails sind nicht als reines Layout gekennzeichnet. Die Folge: Hilfsmittel kündigen bedeutungslose Tabellenstrukturen an und verwirren die Nutzer. Ein role=presentation an der äußeren Layout-Tabelle, und echte Kopfzellen nur dort, wo wirklich Daten stehen, trennt beide Fälle sauber.

Kontrast, Schriftgröße und Dark Mode

Drei visuelle Faktoren entscheiden darüber, ob eine E-Mail lesbar bleibt: Kontrast, Schriftgröße und das Verhalten im Dark Mode. Für normalen Text verlangt WCAG 2.1 ein Kontrastverhältnis von mindestens 4,5:1 (W3C, WCAG 2.1), für großen Text, ab 24 Pixel beziehungsweise 18 Punkt (W3C, WCAG 2.1) oder 14 Punkt fett, genügen 3:1 (W3C, WCAG 2.1). Diese Werte sind messbar und gehören als feste Tokens in die Vorlage. Blasse Buttons und hellgraue Fußzeilen sind die häufigsten Kontrastfehler in E-Mails.

Kontrast mindestens 4,5:1

Text auf Hintergrund erreicht 4,5:1, große Überschriften 3:1. Dünne Grautöne im Footer und blasse Call-to-Actions sind die typischen Ausreißer (WCAG 1.4.3).

Schrift ausreichend groß

Fließtext ab etwa 14 bis 16 Pixel bleibt auf kleinen Displays lesbar. Zu kleine Schrift wird von manchen Mobil-Clients automatisch skaliert und bricht das Layout.

Robust im Dark Mode

Viele Clients färben E-Mails automatisch um. Transparente Logos mit passender Kontur und getestete Farbpaare verhindern, dass Text im dunklen Modus verschwindet.

Dark Mode ist kein Sonderfall mehr

E-Mail-Programme greifen im Dark Mode teils tief in die Farben ein: Sie invertieren Hintergründe, hellen dunklen Text auf oder tauschen Farbpaare. Ein schwarzes Logo auf transparentem Grund kann so unsichtbar werden. Wer Farben nicht dem Zufall überlässt, prüft jede Vorlage in hellem und dunklem Modus. Wie Schriftwahl und Größe zusammenspielen, vertieft unser Beitrag zu barrierefreier Typografie und Lesbarkeit; die Grundlagen des Kontrasts erklärt der Beitrag zu Farbkontrasten in der Barrierefreiheit.

Barrierefreie Vorlagen im Team verankern

Eine einzelne geprüfte E-Mail nützt wenig, wenn die nächste Kampagne die alten Fehler wiederholt. Nachhaltige Barrierefreiheit im E-Mail-Marketing entsteht an zwei Stellen: in geprüften Master-Vorlagen und in den Köpfen des Teams, das sie täglich befüllt. Wer Zugänglichkeit von Anfang an mitdenkt, spart die teure Nachbesserung; dieser Grundsatz der Barrierefreiheit von Anfang an gilt für E-Mails ebenso wie für Websites.

  1. Master-Vorlage härten: lang-Attribut, semantische Überschriften, role=presentation an Layout-Tabellen und Kontrast-Tokens einmalig sauber anlegen.
  2. Echten Text erzwingen: Editor und Freigabeprozess so gestalten, dass niemand versehentlich eine reine Bild-E-Mail verschickt.
  3. Alt-Text zur Pflicht machen: Kein inhaltstragendes Bild ohne Beschreibung, dekorative Bilder bewusst mit leerem alt-Attribut.
  4. In hellem und dunklem Modus testen: Jede Vorlage vor dem Livegang in mehreren Clients und beiden Farbmodi prüfen.
  5. Redaktion schulen: Das Team versteht die Regeln und wendet sie eigenständig an, statt sie später mühsam nachzubessern.
  6. Laufend überwachen: Neue Vorlagen und Tool-Updates regelmäßig gegenprüfen, damit keine Barriere zurückkehrt.

Der wirksamste Hebel ist die Redaktion selbst. Werkzeuge finden Barrieren, aber vermeiden können sie nur Menschen, die wissen, worauf es ankommt. Deshalb verbinden wir geprüfte Vorlagen mit einer Schulung für das Marketing-Team, die aus abstrakten Kriterien konkrete Routinen macht, vom Alt-Text bis zum Dark-Mode-Check. Wie sich barrierefreie Redaktionsarbeit organisieren lässt, zeigt unser Beitrag zur Schulung des Redaktionsteams. Den Bestand erhebt ein WCAG-Audit, das die Vorlagen bewertet und in unsere barrierefreie Umsetzung einbettet, während ein laufendes BFSG-Monitoring meldet, wenn ein Vorlagen-Update eine neue Barriere einführt.

Barrierefreiheit in der E-Mail ist selten eine Frage großer Technik, sondern der kleinen Gewohnheiten: die Sprache auszeichnen, das Bild beschreiben, den Kontrast prüfen, jedes Mal.

Grundsatz aus der Audit-Praxis der barrierefreien Webentwicklung

Quellen und Studien

Dieser Artikel basiert auf Daten und Quellen aus: Email Markup Consortium, Accessibility Report 2026 (Email Markup Consortium), den Erfolgskriterien der W3C Web Content Accessibility Guidelines (WCAG) 2.1 und den Erläuterungen der W3C Web Accessibility Initiative (W3C), der harmonisierten Norm EN 301 549 sowie dem Barrierefreiheitsstärkungsgesetz (BFSG) und der Richtlinie (EU) 2019/882 (European Accessibility Act) des Bundesministeriums für Arbeit und Soziales. Rechtliche Hinweise ersetzen keine individuelle Rechtsberatung.