Barrierefreie E-Mails
Barrierefreie E-Mail-Newsletter und HTML-E-Mail-Vorlagen nach WCAG 2.2 AA
Barrierefreie E-Mail-Newsletter sind E-Mails, denen Menschen mit Screenreader folgen können, die auch mit abgeschalteten Bildern verständlich bleiben und die auf einem 320 Pixel breiten Smartphone-Bildschirm und im Dark Mode lesbar sind. Ich erstelle neue Newsletter- und Benachrichtigungsvorlagen und überarbeite die, die Sie bereits versenden. Dazu gehören als Präsentation ausgezeichnete Layouttabellen, echte Überschriften, Alternativtexte, echter Text statt Text im Bild, ausreichender Kontrast, Linktexte, die ihr Ziel nennen, eine hinterlegte Sprache, Dark-Mode-Stile und ein Nur-Text-Teil, alles deutlich unter der Größe, ab der Gmail eine Nachricht kürzt. Sie erhalten HTML zum Import in Ihr Versandtool, mit axe-core-Berichten und einer klaren Liste dessen, was die Prüfungen nicht abgedeckt haben.
Kurz gesagt
Das mache ich
- Ich erstelle barrierefreie HTML-Vorlagen für Newsletter, Kampagnen und Shop-Benachrichtigungen wie Bestell- und Versandbestätigungen oder überarbeite Ihre bestehende Vorlage.
- Ich ersetze Angebote, die nur im Bild stehen, durch echten HTML-Text und Bild-Buttons durch programmierte („bulletproof“) Buttons.
- Ich setze Überschriften, Alternativtexte, Linktexte, Sprache, Kontrast, Dark-Mode-Stile, einen Vorschautext (Preheader) und eine Nur-Text-Version.
- Sie erhalten Vorher-nachher-Berichte von axe-core, Kontrasttabellen für hellen und dunklen Modus, Screenshots und einen Befundbericht.
Nicht Teil dieser Leistung
- Ihre Texte umschreiben. Ich ändere die Struktur, nicht Ihre Werbetexte. Ausnahmen sind Linktexte, Alternativtexte und die Nur-Text-Version, und jede davon geben Sie frei.
- Arbeit in Ihrem Versandtool. Ich liefere HTML, das Sie oder Ihre Entwicklerin bzw. Ihr Entwickler in Mailchimp, Klaviyo, Brevo, Shopify, WooCommerce oder ein anderes Tool importieren. Getestete Integrationen mit diesen Tools behaupte ich nicht.
- Zustellbarkeit. Spam-Bewertung, SPF, DKIM, DMARC und Listenpflege sind nicht enthalten.
- Tests in echten E-Mail-Programmen und mit Screenreadern, abgesehen vom unten beschriebenen optionalen Schritt.
- Rechtsberatung. Ob BFSG oder BaFG für Ihre E-Mails gelten und ob Ihre Werbe-E-Mails UWG und DSGVO (etwa beim Double-Opt-in) genügen, klärt Ihre Rechtsberatung.
Ist diese Seite für Sie?
Sie sind hier richtig, wenn einer dieser Punkte auf Sie zutrifft:
- Sie sind Onlinehändler mit Verbraucherkunden, und Newsletter sowie Bestellmails gehören zu Ihrer BFSG- oder BaFG-Umsetzung.
- Ihre Agentur liefert jeden Newsletter als ein großes Bild, mit Rabatt, Gutscheincode und Enddatum darin.
- Sie sind eine Agentur, die für Kunden Vorlagen in Mailchimp, Klaviyo oder Brevo baut, und ein Kunde oder eine Ausschreibung verlangt WCAG AA.
- Ihre E-Mails scrollen auf dem Smartphone seitlich oder werden im Dark Mode unlesbar, und Sie möchten den Grund kennen, bevor Sie ein Redesign bezahlen.
Prüfen Sie Ihren letzten Newsletter in einer Minute
- Bilder aus: Schalten Sie das automatische Laden von Bildern in Ihrem E-Mail-Programm ab (in Gmail im Browser: Einstellungen → Alle Einstellungen aufrufen → Allgemein → Bilder) und öffnen Sie Ihre letzte Kampagne. Können Sie Angebot, Code und Enddatum noch lesen?
- Linktexte: Lesen Sie nur die Links. „Hier klicken“ und „Mehr“ sagen Menschen mit Screenreader, die oft von Link zu Link springen, nichts.
- Smartphone: Müssen Sie seitlich scrollen, hat das Layout eine feste Breite.
- Größe: Steht am Ende einer Gmail-Nachricht der Hinweis, dass sie gekürzt wurde, ist das HTML zu groß, und alles danach, oft auch der Abmeldelink, ist verborgen.
Lesen Sie weiter für die technischen Details. Unten: was eine HTML-E-Mail barrierefrei macht, ein gemessenes Vorher-nachher-Beispiel an einem fiktiven Shop-Newsletter (alle Dateien zum Download) und die Rechtslage für den Onlinehandel in Deutschland, Österreich und der EU. Wenn Sie abkürzen möchten, leiten Sie mir einen Newsletter weiter, und ich sage Ihnen, was daran nicht stimmt.
Was eine HTML-E-Mail barrierefrei macht
Eine barrierefreie E-Mail transportiert ihre Botschaft in echtem, strukturiertem HTML-Text statt in Bildern und Gestaltung, denn E-Mail-Programme blockieren Bilder, entfernen CSS und betten Ihre Nachricht in ihre eigene Seite ein.
Layouttabellen als Präsentation ausgezeichnet
E-Mails werden nach wie vor mit Tabellen gesetzt, weil Outlook unter Windows HTML mit der Word-Engine darstellt. Eine Layouttabelle ohne role="presentation" kann als Datentabelle angesagt werden, mit Zeilen und Spalten, die nichts bedeuten; als Präsentation ausgezeichnet, wird das Raster übersprungen und nur der Inhalt gelesen.
Echte Überschriften und eine sinnvolle Lesereihenfolge
Eine Tabellenzelle, die nur wie eine Überschrift formatiert ist, lässt sich über die Überschriftennavigation nicht erreichen. Echte h1–h3-Elemente erlauben es, einen Newsletter Abschnitt für Abschnitt zu durchlaufen, auch im Webmailer. Stapeln sich die Spalten auf dem Smartphone, wird die Quelltext-Reihenfolge zur Lesereihenfolge; der Quelltext folgt also der Reihenfolge, in der die Nachricht gelesen werden soll.
Echter Text statt Text im Bild, und Alternativtexte
Viele E-Mail-Programme zeigen Bilder erst, wenn die Leserin oder der Leser es erlaubt. Stehen Rabatt, Code und Datum nur in einem Bild, sieht man ein leeres Feld, und der Screenreader sagt nichts Brauchbares an. Informative Bilder brauchen einen Alternativtext, der sagt, was sie zeigen (WCAG 2.2, 1.1.1); dekorative erhalten alt="" und werden übersprungen. Buttons sind formatierte Links mit VML-Fallback für Outlook, keine Bilder von Buttons.
Kontrast, Schriftgröße und Linktext
Text braucht einen Kontrast von mindestens 4,5:1 zum Hintergrund, bei großer Schrift 3:1 (WCAG 2.2, 1.4.3); hellgraue Fußzeilen in 9 oder 10 Pixeln sind die Stelle, an der Newsletter am sichtbarsten scheitern. Linktexte nennen ihr Ziel, etwa „Keramikbecher ansehen“ oder „Newsletter abbestellen“, damit eine Linkliste auch für sich verständlich ist (WCAG 2.2, 2.4.4).
Sprache, Dark Mode, Nur-Text-Teil und Größe
Ich setze lang und dir auf das <html>-Element und zusätzlich auf den Container der Nachricht, weil Webmailer das <html>-Element oft verwerfen. Ein <title> und ein Vorschautext geben der Nachricht einen Namen und eine Vorschauzeile. Der Dark Mode braucht eine eigene Palette: Manche Apps folgen prefers-color-scheme-Stilen, andere invertieren Farben auf eigene Faust. Ein Nur-Text-Teil in einer multipart/alternative-Nachricht dient Menschen und Programmen, die kein HTML anzeigen, und ein List-Unsubscribe-Header mit Ein-Klick-Abmeldung (RFC 8058) lässt das E-Mail-Programm seinen eigenen Abmelde-Button zeigen. Gmail kürzt Nachrichten, deren HTML größer als etwa 102 KB ist.
Nachweis: ein Shop-Newsletter, vorher und nachher
Dies ist ein gemessenes Beispiel an einem fiktiven Newsletter, keine Kundenarbeit. Ich habe eine typische bildlastige Kampagnen-E-Mail gebaut, gemessen, barrierefrei neu aufgebaut und in Headless-Chromium erneut gemessen. Kein echtes E-Mail-Programm und kein Screenreader kamen zum Einsatz; die Grenzen stehen unten. Alle Dateien stehen zum Download bereit.
Quelle und Lizenz
- Inhalt: Alles ist fiktiv. Der Newsletter gehört zu einem erfundenen türkischen Shop, „Örnek Mağaza — Ekim kampanyası“ (eine Oktober-Aktion), und ist auf Türkisch geschrieben. Shop, Adresse, Produkte, Preise, der Code
EKIM40und die reservierte, nicht auflösbare Domainornek-magaza.exampleexistieren nicht. Beide Fußzeilen sagen das, und die .eml trägt einenX-Example-Notice-Header. - Bilder: einfache Formen, die ich gezeichnet habe; die Social-Media-Symbole sind neutrale Buchstabenkreise, keine Markenlogos. Es werden keine Inhalte Dritter verwendet; die Dateien dürfen als Beispiele weiterverwendet werden.
- Werkzeuge: axe-core 4.13.0 mit den Tags
wcag2a,wcag2aa,wcag21a,wcag21aa,wcag22aundwcag22aa, in Chromium 141.0.7390.37 (headless, gesteuert über Playwright 1.56.0). Dazu mein eigenes Prüfskript für Farbpaare, Schriftgrößen, Alternativtexte, Links, Tabellen, die Ansicht ohne Bilder, einen 320 Pixel breiten Viewport und den emulierten Dark Mode.
Der Newsletter ist auf Türkisch; Berichte und Nachweisbilder sind auf Englisch.
Was axe-core gemeldet hat
| Regel | WCAG | Vorher (Elemente) | Nachher (Elemente) |
|---|---|---|---|
color-contrast | 1.4.3 | 16 | 0 |
image-alt | 1.1.1 | 9 | 0 |
link-name | 2.4.4, 4.1.2 | 8 | 0 |
html-has-lang | 3.1.1 | 1 | 0 |
document-title | 2.4.2 | 1 | 0 |
| Verletzte Regeln / Elemente | – | 5 / 35 | 0 / 0 |
Vorher meldete axe zusätzlich einen Punkt zur manuellen Prüfung (bypass), nachher keinen. Von den Best-Practice-Regeln, die keine WCAG-Anforderungen sind, erscheinen landmark-one-main und region auch nach dem Umbau. Das ist Absicht: Das E-Mail-Programm bettet die Nachricht in seine eigene Seite und seine eigenen Landmarks ein, ein <main>-Element in der E-Mail hilft dort nicht. Die neue Fassung nutzt stattdessen role="article" mit einem aria-label.
Was ich außerdem gemessen habe
| Gemessen | Vorher | Nachher |
|---|---|---|
| Angebotsangaben lesbar ohne Bilder (%40, EKIM40, 31 Ekim, kostenloser Versand, 500 TL, Wohnartikel) | 0 von 6 | 6 von 6 |
Layouttabellen mit role="presentation" | 0 von 10 | 6 von 6 |
| Echte Überschriften | 0 (formatierte Zellen) | 6 (h1: 1, h2: 2, h3: 3) |
Bilder: gesamt / ohne Alt-Attribut / dekorativ alt="" | 9 / 9 / 0 | 8 / 0 / 4 |
| Links mit allgemeinem oder leerem Namen | 14 von 14 | 0 von 12 |
| Farbpaare unter 4,5:1 (große Schrift 3:1), hell | 8 von 9 (niedrigster 1,61:1) | 0 von 16 (niedrigster 6,99:1) |
| Dasselbe im emulierten Dark Mode | 8 von 9 (keine Dark-Mode-Stile) | 0 von 16 (niedrigster 8,7:1) |
| Kleinste Schrift | 9 px | 14 px (Fließtext 16 px, Zeilenhöhe 24 px) |
| Dokumentbreite im 320-px-Viewport | 600 px (280 px seitliches Scrollen) | 320 px (Spalten gestapelt) |
lang / dir, <title>, Vorschautext | keine / keine, fehlt, keiner | tr / ltr, vorhanden, vorhanden |
| Nur-Text-Alternative | keine | ja, in multipart/alternative |
| HTML-Größe (Gmail kürzt ab etwa 102 KB) | 5.543 Byte | 12.137 Byte (12.392 in der .eml) |
Vollständige Kontrasttabellen für hellen und dunklen Modus mit jedem Farbpaar stehen in der axe-Zusammenfassung im ZIP.
Was ich geändert habe
- Das Angebot: Es stand nur in einem 600×300-Bild ohne Alternativtext. Jetzt ist es echter Text auf einfarbigem
#7c2d12-Hintergrund; das Kopfbild darüber ist dekorativ (alt=""). - Button und Bilder: Aus dem Bild-Button wurde ein formatierter Link in einer Präsentationstabelle, mit VML-Fallback
v:roundrectfür Outlook. Der Logo-Link lautet „Örnek Mağaza ana sayfa“ (Startseite), Produkte haben beschreibende Alternativtexte, und die Social-Media-Symbole sind neben sichtbarem Linktext als dekorativ markiert. - Links: Aus „Buraya tıklayın“ (hier klicken) und „Devamı“ (mehr) wurden Texte wie „Seramik kupayı inceleyin“ (Keramikbecher ansehen) und „Abonelikten çıkın“ (abbestellen).
- Farbe, Größe und Struktur: 16-px-Fließtext in
#1f2937,#4b5563und#9a3412; h1 bis h3;lang="tr" dir="ltr", ein Titel und ein Vorschautext; ein flexibler Container mit maximal 600 px, dessen Spalten sich ab 620 px und darunter stapeln. - Dark Mode und Nachricht:
color-scheme-Meta-Tags, eineprefers-color-scheme: dark-Palette,[data-ogsc]-Regeln und eine weiße Fläche hinter dem Logo; ein Nur-Text-Teil in einermultipart/alternative-.eml mitList-Unsubscribe– und Ein-Klick-Headern.

Was die Prüfungen nicht melden
„Hier klicken“ besteht
Die axe-Regel link-name meldete 8 Links, die ganz ohne Namen. Meine eigene Liste fand 14 von 14 allgemein oder leer: „Buraya tıklayın“ hat einen Namen, also akzeptiert axe ihn.
Ein Angebot im Bild
axe fragt nur, ob ein Alternativtext existiert. Ein Alt-Text wie „Oktober-Aktion“ hätte genügt, während Rabatt, Code und Datum ohne Bilder unsichtbar bleiben. Der Test ohne Bilder sucht sechs Angaben im echten Text.
Der Dark Mode der Apps
Mein Ergebnis ist die Chromium-Emulation von prefers-color-scheme: dark. Gmail-Apps und Outlook erzwingen eigene Farbumkehrungen, die sie nicht nachbildet.
Darstellung in echten Programmen
Outlook, Gmail, Apple Mail, Yahoo und Samsung Mail wurden nicht getestet. Outlook ignoriert border-radius und Media Queries; VML-Button und [data-ogsc]-Regeln folgen gängigen Mustern, wurden dort aber nicht überprüft.
Es wurde kein Screenreader verwendet (NVDA, JAWS, VoiceOver, TalkBack); axe prüft den Code, nicht, was ein Screenreader im Webmailer ansagt. Keine automatische Prüfung beurteilt, ob ein Alternativtext gut ist, ob die Lesereihenfolge Sinn ergibt oder ob die Sprache verständlich ist; das habe ich von Hand geprüft. Mein Kontrastskript kann Text in oder über Bildern nicht messen. Die Größe ist die der Rohdatei; Versandtools fügen Tracking hinzu, der tatsächliche Abstand zur Gmail-Grenze ist also kleiner. Zustellbarkeit, Authentifizierung und rechtliche Prüfungen gehörten nicht zum Beispiel.

Dateien herunterladen und vergleichen
| Datei | Inhalt | Größe |
|---|---|---|
| Beispiel (ZIP) | HTML vorher und nachher, die .eml mit Nur-Text-Teil und eingebetteten Bildern, der Nur-Text-Teil einzeln, axe-core-Rohdaten (JSON), die axe-Zusammenfassung mit vollständigen Kontrasttabellen (HTML), alle Screenshots, die Bilder und die Befunde | 1,5 MB |
| Vorher, Desktop | Screenshot bei 800 px, Bilder an | 68 KB |
| Nachher, Desktop | Screenshot bei 800 px, Bilder an | 122 KB |
| Nachher, Dark Mode | Chromium-Emulation von prefers-color-scheme: dark, keine Mail-App | 120 KB |
| Vorher und nachher bei 320 px | Erster Bildschirm eines 320-px-Viewports, nebeneinander, in doppelter Auflösung | 216 KB |
HTML-, .eml-, Nur-Text- und JSON-Dateien gibt es nur im ZIP. Die Berichte sind auf Englisch.
Was Sie bekommen
Sie erhalten eine importfertige HTML-Vorlage, ihre Nur-Text-Version und Berichte, die zeigen, was gemessen wurde und was nicht.
- Die barrierefreie HTML-Vorlage, wobei Merge-Tags und Template-Variablen Ihrer bisherigen Fassung erhalten bleiben.
- Eine Nur-Text-Version und einen Vorschautext zur Freigabe.
- Vorher-nachher-Berichte von axe-core, Kontrasttabellen für hellen und dunklen Modus sowie Screenshots in Desktop-Breite, bei 320 px, ohne Bilder und im emulierten Dark Mode.
- Einen Befundbericht, auch dazu, was bewusst so bleibt und was die Prüfungen nicht sehen, und eine einseitige Notiz für alle, die künftige Kampagnen erstellen.
Mailchimp, Klaviyo und Brevo nehmen eigenes HTML als benutzerdefinierte Vorlage an; Shopify-Benachrichtigungen werden im Shop-Admin als Code bearbeitet, WooCommerce-E-Mails über Template-Overrides im Theme. Sie oder Ihr Entwicklungsteam importieren das HTML und senden sich einen Test; was falsch ankommt, korrigiere ich. Haben Sie ein Konto bei einem E-Mail-Testdienst wie Litmus oder Email on Acid, prüfe ich dessen Screenshots aus verschiedenen Programmen als optionalen Schritt; ohne ein solches Konto nennt der Bericht das als Grenze.
Ablauf
Sie senden zuerst eine echte E-Mail; der Preis steht fest, bevor die Arbeit beginnt.
- Leiten Sie einen Newsletter weiter oder senden Sie seinen HTML-Export: die Kampagne oder Bestellmail, die Ihnen die meisten Sorgen macht. Ich sage Ihnen, was tatsächlich nicht stimmt, einschließlich dessen, was die Korrektur nicht lohnt.
- Sie erhalten Umfang und Festpreis für diese Vorlage oder das ganze Set.
- Ich erledige die Arbeit. Sie erhalten eine als Vorschau gekennzeichnete Fassung mit axe-core-Bericht, Screenshots und einer Liste der Farb- oder Textänderungen zur Freigabe.
- Mit Ihrer Freigabe erhalten Sie die finalen Dateien: HTML, Nur-Text-Version und Befundbericht.
Preis
Ich kalkuliere jeden Auftrag, nachdem ich das Material gesehen habe. Die Zahl der E-Mails allein bestimmt den Aufwand nicht: Eine modulare Mastervorlage, die alle Kampagnen nutzen, kann weniger Zeit kosten als drei einzelne Newsletter aus Bildern. Sie erhalten vor Beginn einen Festpreis für das Set, ohne Stundenabrechnung. Teilen Ihre Kampagnen eine Vorlage, ist es meist günstiger, diese Vorlage zu korrigieren, und das sage ich Ihnen dann auch.
Warum das jetzt wichtig ist
Seit dem 28. Juni 2025 fallen Dienstleistungen im elektronischen Geschäftsverkehr für Verbraucher unter das Barrierefreiheitsstärkungsgesetz (BFSG). Ob und wie weit das Ihre Newsletter und Bestellmails erfasst, ist eine Rechtsfrage.
Rechtlicher Hinweis: Diese Seite behandelt die technische Seite. Ob BFSG oder BaFG für Ihren Shop und für welche Ihrer E-Mails gelten, klären Sie bitte mit Ihrer Rechtsberatung.
- Der European Accessibility Act, Richtlinie (EU) 2019/882, erfasst den elektronischen Geschäftsverkehr; die Mitgliedstaaten wenden ihre nationalen Gesetze seit dem 28. Juni 2025 an. In Deutschland nennt das BFSG in § 1 Abs. 3 Nr. 5 „Dienstleistungen im elektronischen Geschäftsverkehr“. Die Richtlinie beschreibt diese Dienstleistungen über Websites und mobile Anwendungen; E-Mail nennt sie nicht als eigenen Kanal.
- Österreich: Das Barrierefreiheitsgesetz (BaFG) setzt die Richtlinie um und gilt ebenfalls seit dem 28. Juni 2025.
- Artikel 4 Absatz 5 der Richtlinie nimmt Kleinstunternehmen, die Dienstleistungen erbringen, aus. Ob das auf Sie zutrifft, klärt Ihre Rechtsberatung.
- Der technische Maßstab in der Praxis sind die WCAG 2.2, Stufe AA. Sie sind für Web-Inhalte geschrieben; eine HTML-E-Mail besteht aus denselben Technologien.
Shops in der Schweiz oder außerhalb Europas betrifft das über ihre Verkäufe an Verbraucher in der EU. Und auch ohne Gesetz gilt: Ein Angebot, das man mit blockierten Bildern, auf dem Smartphone oder im Dark Mode nicht sieht, verkauft nicht.
Häufige Fragen
Funktioniert die Vorlage in Mailchimp, Klaviyo oder Brevo?
Diese Tools nehmen benutzerdefinierte HTML-Vorlagen an, und dafür schreibe ich das HTML. Importe in bestimmte Plattformen habe ich nicht getestet; Sie oder Ihr Entwicklungsteam importieren und senden einen Test. Ich übernehme Ihre Merge-Tags und korrigiere, was der Import zerlegt.
Haben Sie in Outlook, Gmail und Apple Mail getestet?
Im Beispiel nicht: Gemessen wurde nur in Headless-Chromium, und das sage ich offen. Haben Sie ein Konto bei einem E-Mail-Testdienst, prüfe ich dessen Screenshots als optionalen Schritt. Andernfalls bleibt die Darstellung in echten Programmen eine im Bericht genannte Grenze.
Testen Sie mit einem Screenreader?
Nein, und ich behaupte nichts anderes. Meine Befunde stammen aus dem Code, den Normen, axe-core und manueller Prüfung. Tests durch Menschen, die assistive Technologien nutzen, sollten gesondert beauftragt werden.
Darf unsere Agentur den Newsletter weiter als ein Bild liefern?
Genau das sollte aufhören. Im Beispiel konnte jemand mit blockierten Bildern vorher 0 der 6 Angebotsangaben lesen, nachher alle 6. Bilder können als Dekoration oder Produktfoto bleiben; das Angebot selbst gehört in echten Text.
Wird die E-Mail zu groß für Gmail?
Barrierefreier Code bringt etwas mehr Gewicht, aber nicht viel. Im Beispiel wuchs das HTML von 5.543 auf 12.137 Byte, weit unter Gmails Kürzungsgrenze von etwa 102 KB. Versandtools fügen Tracking-Code hinzu, deshalb messe ich auch die Größe Ihres echten Exports.
Gilt das BFSG für unsere Newsletter?
Das ist eine Rechtsfrage, und Ihre Rechtsberatung entscheidet sie. Das Gesetz erfasst Dienstleistungen im elektronischen Geschäftsverkehr; die Richtlinie beschreibt sie über Websites und Apps und nennt E-Mail nicht gesondert. Ich baue in jedem Fall nach WCAG 2.2 AA und dokumentiere, was geprüft wurde.
Verwandte Leistungen
Senden Sie mir einen Newsletter
Eine E-Mail: die Kampagne, Bestellbestätigung oder Vorlage, die Ihnen die meisten Sorgen macht. Leiten Sie sie so weiter, wie sie bei Ihnen angekommen ist. Sie erhalten eine klare Einschätzung, was daran nicht stimmt, einschließlich dessen, was die Korrektur nicht lohnt.
Ali Karabüyük · Tekirdağ, Türkei · Zusammenarbeit aus der Ferne, weltweit · Dokumenten- und Bildproduktion seit 2004, hauptberuflich seit 2008.

