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.
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
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-Typ | Typische Beispiele | Einordnung | Empfehlung |
|---|---|---|---|
| Transaktionsmail | Bestellbestätigung, Rechnung, Versand, Passwort-Reset | Teil der elektronischen Dienstleistung | Barrierefrei nach WCAG umsetzen |
| Service-Mail | Terminerinnerung, Statusupdate, Kontobenachrichtigung | Eng mit der Dienstleistung verbunden | Wie Transaktionsmails behandeln |
| Werbe-Newsletter | Angebote, Rabatte, Content-Digest | In der Regel keine eigene Dienstleistung | Zugänglich als Standard und Reichweitenvorteil |
| Mischform | Newsletter mit Rechnungslink oder Kontofunktion | Einordnung im Einzelfall | Im 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
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
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.
<!-- 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
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
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.
| Aspekt | Layout-Tabelle | Echte Datentabelle |
|---|---|---|
| Zweck | Ordnet Blöcke visuell an | Stellt Zeilen und Spalten in Beziehung |
| Rolle | role=presentation, damit stumm | Als Tabelle mit Kopfzellen angesagt |
| Kopfzellen | Keine th-Elemente nötig | th mit scope für Zeile und Spalte |
| Screenreader | Liest den Inhalt der Reihe nach | Nennt 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
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
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.
- Master-Vorlage härten: lang-Attribut, semantische Überschriften, role=presentation an Layout-Tabellen und Kontrast-Tokens einmalig sauber anlegen.
- Echten Text erzwingen: Editor und Freigabeprozess so gestalten, dass niemand versehentlich eine reine Bild-E-Mail verschickt.
- Alt-Text zur Pflicht machen: Kein inhaltstragendes Bild ohne Beschreibung, dekorative Bilder bewusst mit leerem alt-Attribut.
- In hellem und dunklem Modus testen: Jede Vorlage vor dem Livegang in mehreren Clients und beiden Farbmodi prüfen.
- Redaktion schulen: Das Team versteht die Regeln und wendet sie eigenständig an, statt sie später mühsam nachzubessern.
- 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.
Quellen und Studien