HTML-E-Mail-Barrierefreiheit: Ein Entwicklerhandbuch

Für Teams, die HTML-E-Mails als Code entwickeln und die Barrierefreiheit selbst kontrollieren wollen, ist MJML der naheliegende Ausgangspunkt. Das Framework setzt aus wenigen Komponenten Tabellen-HTML zusammen, das Sie im fertigen Ergebnis prüfen können. Der Preis ist auf der Anbieterseite nicht als Abo ausgewiesen: MJML wird selbst gehostet, die Preisseite führt keine Abo-Stufen. Der Preis lautet daher auf Anfrage. Wichtig: Das Framework macht Ihre Mails nicht automatisch barrierefrei. Alt-Texte, Überschriftenfolge und Kontraste müssen Sie trotzdem setzen und prüfen.

Dieser Artikel richtet sich an E-Mail-Entwickler und Marketingteams, die einen Builder oder ein Framework auswählen und dabei wissen wollen, welche Barrierefreiheitsaufgaben das Werkzeug abnimmt und welche bei Ihnen bleiben. Wir gehen zuerst auf die Werkzeuge ein, danach auf die Techniken, die in jedem Builder gleich gelten.

Preisangaben stammen von den offiziellen Preisseiten der Anbieter und wurden am 7. Oktober 2026 geprüft. Preise ändern sich; prüfen Sie die Angaben bei jeder Verlängerung erneut.

Warum der Builder über Barrierefreiheit mitentscheidet

E-Mail ist eines der schwierigsten Medien für Barrierefreiheit. Die Ausgabe hängt vom Mail-Client ab, und viele Clients ignorieren moderne Standards. Deshalb setzen Builder auf Tabellen, Inline-Styles und feste Breiten. Genau diese Techniken bringen Screenreader durcheinander, wenn niemand sie bewusst einsetzt.

Ein Builder kann an drei Stellen helfen: er erzeugt ein stabiles Grundgerüst, er erzwingt Pflichtfelder wie Alt-Text und er bietet eine Vorschau, mit der Sie Kontraste und Umbrüche sehen. Keiner dieser Punkte ersetzt die Prüfung. Ein Editor kann einen leeren Alt-Text durchgehen lassen, und ein Framework kann eine falsche Überschriftenebene exakt so ausgeben, wie man sie eingetippt hat.

Die Entscheidung für ein Werkzeug sollte deshalb auf zwei Fragen beruhen: Wer schreibt die Mails, und wo kann die Barrierefreiheit verloren gehen? Ein Entwicklerteam braucht Kontrolle über den Code und Tests in der Pipeline. Ein Marketingteam braucht eine Oberfläche, in der Pflichtangaben nicht übersprungen werden können.

Die Werkzeuge im Überblick

Die folgende Tabelle fasst zusammen, für wen die einzelnen Werkzeuge gedacht sind, was sie kosten und wo sie für Barrierefreiheit Grenzen haben. Wo es keine geprüfte Preisangabe gibt, steht „auf Anfrage“.

MJML: Komponenten mit prüfbarem Ergebnis

MJML beschreibt eine Mail mit eigenen Tags wie Abschnitten, Spalten und Textblöcken. Beim Übersetzen in HTML entstehen Tabellen, die Sie im Ausgabecode lesen und prüfen können. Für Barrierefreiheit ist das ein Vorteil: Sie sehen, welche Tabelle ein Layout ist und welches Element wirklich Inhalt trägt.

Was MJML gut macht: Die Ausgabe ist vorhersehbar, Komponenten lassen sich wiederverwenden, und Änderungen zeigen sich als Diff in der Versionsverwaltung. Ein Team kann Regeln wie „jedes Bild braucht ein alt-Attribut“ in einer eigenen Komponente festschreiben, sodass sie nicht bei jeder Mail neu vergessen werden.

Wo MJML zu kurz greift: Das Framework kennt Ihre Inhalte nicht. Es erzwingt keinen Alt-Text und prüft keine Überschriftenfolge. Wer MJML einsetzt, braucht einen Prüfschritt im Build oder vor dem Versand. Außerdem muss das Team das Framework selbst betreiben.

Preis: Auf Anfrage. Die Preisseite des Anbieters listet keine Abo-Stufen. Quelle: MJML-Preisseite.

React Email: Vorlagen als Komponenten im Entwicklungs-Stack

React Email erlaubt es, E-Mails als React-Komponenten zu schreiben und sie zu HTML zu rendern. Für Teams, die bereits mit React arbeiten, ist das der kürzeste Weg von der Oberflächenkomponente zur Mail. Gemeinsame Bausteine wie Kopfzeile, Button oder Fußzeile lassen sich über Props steuern, und Tests können direkt auf dem gerenderten HTML laufen.

Stärke für Barrierefreiheit: Alt-Text, Sprachattribut und Überschriften sind Props und Elemente im Code. Ein Lint-Regelwerk oder ein Komponententest kann fehlende Angaben finden, bevor die Mail den Entwickler verlässt.

Grenze: Das Rendering in Outlook und anderen Desktop-Clients unterscheidet sich vom Browser. Eine Komponente, die im Test sauber aussieht, kann im Posteingang anders wirken. Planen Sie deshalb eine Testrunde mit echten Clients ein.

Preis: Auf Anfrage. Für dieses Werkzeug liegt in unserer Prüfung keine Preisangabe vor.

Maizzle: utility-basiertes CSS mit Build-Schritt

Maizzle baut E-Mails aus Templates mit utility-artigen CSS-Klassen. Beim Build werden die Styles in Inline-CSS übersetzt, wie es viele Mail-Clients verlangen. Das Ergebnis ist eine fertige HTML-Datei, die Sie an den Versanddienst übergeben.

Stärke für Barrierefreiheit: Die Trennung von Layout und Inhalt macht es leichter, Farben und Kontraste zentral zu definieren. Sie können Kontrastwerte in einer Konfigurationsdatei festlegen und im Build prüfen lassen.

Grenze: Der Build-Schritt gehört in die Pipeline. Wer ihn umgeht und Dateien direkt hochlädt, verliert die Kontrollpunkte. Auch hier müssen Alt-Texte und Überschriftenebenen im Template gepflegt werden.

Preis: Auf Anfrage. Für dieses Werkzeug liegt in unserer Prüfung keine Preisangabe vor.

Stripo, BEE und Unlayer: Editoren für Marketingteams

Stripo, BEE und Unlayer sind visuelle Editoren. Marketingteams setzen Blöcke per Drag-and-drop zusammen, wählen Farben und Schriften und exportieren oder übergeben das Ergebnis. Ihr Vorteil liegt in der Geschwindigkeit: Eine wiederkehrende Newsletter-Vorlage lässt sich ohne Entwickler anpassen.

Für Barrierefreiheit gilt bei diesen Editoren ein klares Muster. Die Oberfläche kann Pflichtfelder wie Alt-Text anzeigen, aber sie entscheidet nicht über den Inhalt. Prüfen Sie daher drei Dinge bei jedem Editor:

• Lässt sich ein Bild ohne Alt-Text speichern, und wird das sichtbar gekennzeichnet?
• Sind Überschriften als Überschriftenelemente wählbar, oder erzeugt jeder Textblock dasselbe Markup?
• Welche Tabellenstruktur liegt im exportierten Code, und trägt sie role="presentation"?

Stripo eignet sich für Teams mit festen Vorlagen. Achten Sie darauf, dass Vorlagen-Updates bestehende Alt-Texte nicht überschreiben.

BEE ist für Produkte gedacht, die den Editor in eigene Oberflächen einbetten. Die Barrierefreiheit hängt dann stark von der Konfiguration ab, die Ihr Team festlegt.

Unlayer richtet sich ebenfalls an Anbieter, die einen Editor in ihre Anwendung integrieren. Legen Sie fest, welche Blöcke und Einstellungen Nutzer sehen, damit Pflichtangaben nicht umgangen werden.

Preise: Für Stripo, BEE und Unlayer liegt in unserer Prüfung keine Preisangabe vor. Die Preise sind auf Anfrage bzw. auf den jeweiligen Anbieterseiten zu erfragen.

Email on Acid: Prüfwerkzeug statt Builder

Email on Acid baut keine Mails, sondern prüft sie. Die Plattform zeigt Vorschauen in vielen Mail-Clients und Geräten. Laut Preisseite umfasst der Basic-Tarif 1.000 Vorschauen pro Monat über 100 Clients und Geräte sowie API-Zugang. Der Premium-Tarif umfasst 2.000 Vorschauen pro Monat, zusätzlich Barrierefreiheitstests und eine HTML-Analyse.

Für Barrierefreiheit ist vor allem der Premium-Tarif interessant, weil er die Barrierefreiheitstests enthält. Sie ersetzen aber keine manuelle Prüfung mit einem Screenreader. Ein automatischer Test findet fehlende Alt-Texte und einige Kontrastprobleme. Er kann nicht beurteilen, ob ein Alt-Text sinnvoll ist oder ob die Reihenfolge der Inhalte beim Vorlesen stimmt.

Preis: Basic 99 US$ pro Monat, Premium 199 US$ pro Monat, jeweils monatlich abgerechnet. Einen kostenlosen Plan führt die Preisseite nicht auf. Quelle: Email on Acid Preisseite.

Kosten im Vergleich

Die Kosten eines Builders hängen weniger vom Listenumfang ab als von der Zahl der Prüfungen und der Teammitglieder. Bei den Builder-Frameworks und -Editoren nennt die Preisangabe keine festen Stufen, bei Email on Acid zählt das Vorschau-Volumen. Die folgende Tabelle rechnet die festen Angaben ohne Schätzungen durch.

Der Sprung von Basic auf Premium kostet 100 US$ pro Monat, also 1.200 US$ im Jahr. Rechnen Sie ihn gegen den Aufwand, den manuelle Prüfung sonst kostet. Ein Team, das nur Vorlagen mit wenigen Änderungen pro Monat verschickt, kommt oft mit dem Basic-Tarif aus. Ein Team mit vielen Varianten pro Woche sollte die Vorschauzahl vorher zählen.

Semantische Struktur

Unabhängig vom Werkzeug entscheidet die Struktur darüber, wie eine Mail vorgelesen wird. Screenreader kündigen Tabellen an, navigieren über Überschriften und lesen Links einzeln vor. Ihr Markup muss deshalb genau das abbilden, was sichtbar ist.

Layout-Tabellen mit role="presentation" kennzeichnen

E-Mail-Layouts basieren auf Tabellen. Ohne Kennzeichnung kündigt ein Screenreader Tabellennavigation an, etwa „Zeile 1, Spalte 1“, obwohl niemand eine Datentabelle liest. Markieren Sie Layout-Tabellen deshalb mit role="presentation":

<table role="presentation" width="100%">
  <tr>
    <td>
      Layoutinhalt hier
    </td>
  </tr>
</table>

Echte Datentabellen, etwa eine Preisübersicht, bleiben ohne dieses Attribut. Sie brauchen dann eine Kopfzeile mit th-Elementen, damit die Zuordnung beim Vorlesen stimmt.

Überschriften in logischer Reihenfolge

Nutzer von Screenreadern springen gezielt über Überschriften. Eine Mail sollte deshalb eine Hauptüberschrift und darunter Abschnitte in fester Reihenfolge haben. Viele Builder setzen Überschriften nur über Schriftgrößen. Das sieht gleich aus, ist aber für Screenreader unsichtbar:

<h1 style="font-size: 24px; margin: 0;">Willkommen bei unserem Service</h1>
<p>Einleitung ...</p>

<h2 style="font-size: 20px; margin: 20px 0 10px 0;">Neuigkeiten</h2>
<p>Beschreibung ...</p>

<h2 style="font-size: 20px; margin: 20px 0 10px 0;">Erste Schritte</h2>
<p>Anleitung ...</p>

Prüfen Sie nach dem Bauen, ob die Ebenen im Code wirklich h1, h2 und h3 heißen. Eine Mail mit drei fett gesetzten Absätzen und keiner Überschrift ist für Screenreader eine Mail ohne Gliederung.

Listen und Betonung

Verwenden Sie echte Listen für Aufzählungen und strong oder em für Betonung, statt Zeilen mit Bindestrichen zu simulieren. Das wirkt sich nicht auf das Aussehen aus, wohl aber auf das Vorlesen. Eine Liste wird als Liste mit Anzahl der Punkte angekündigt, eine Reihe von Bindestrichen nicht.

Bilder und Alt-Text

Jedes Bild braucht eine Entscheidung: Trägt es Information, oder dient es der Gestaltung? Informative Bilder brauchen einen beschreibenden Alt-Text. Dekorative Bilder brauchen ein leeres alt-Attribut, das Sie bewusst setzen, nicht weglassen.

<!-- Informatives Bild: Inhalt beschreiben -->
<img src="produkt.jpg" alt="Blaue Laufschuhe mit weißen Sohlen" />

<!-- Dekoratives Bild: leerer Alt-Text -->
<img src="trenner.png" alt="" />

<!-- Bild mit Text: den Text übernehmen -->
<img src="aktionsbanner.jpg" alt="50 % Rabatt auf alle Artikel am Wochenende" />

Halten Sie sich an diese Regeln:

• Beschreiben Sie, was das Bild zeigt, nicht dass es ein Bild ist.
• Halten Sie den Alt-Text knapp. Als Faustregel gilt etwa 125 Zeichen.
• Enthält ein Bild Text, geben Sie diesen Text im Alt-Text vollständig wieder.
• Setzen Sie bei Produktbildern den Produktnamen und das entscheidende Merkmal, nicht die Bildunterschrift aus dem Shop.

Keine Information nur im Bild

Viele Empfänger laden Bilder nicht automatisch, und Mail-Clients blockieren sie oft. Wichtige Angaben wie Preis, Frist oder Bestellnummer gehören deshalb als Text in die Mail. Ein Button, der nur als Bild existiert, braucht einen Textlink als Fallback, der den gleichen Zweck erklärt.

Farbe und Kontrast

WCAG 2.1 in der Stufe AA verlangt für normalen Text ein Kontrastverhältnis von mindestens 4,5:1. Für großen Text gilt 3:1. Als groß zählt Text ab 18 pt, also 24 px, oder fett ab 14 pt, also rund 18,7 px. Viele Mail-Vorlagen unterschreiten diese Werte mit hellgrauem Text auf Weiß.

<!-- Guter Kontrast -->
<p style="color: #333333; background-color: #ffffff;">
  Gut lesbarer Text
</p>

<!-- Schwacher Kontrast (vermeiden) -->
<p style="color: #999999; background-color: #ffffff;">
  Schwer lesbarer Text
</p>

Prüfen Sie Farbpaare mit einem Kontrastprüfer, bevor Sie die Vorlage freigeben. Achten Sie besonders auf Fußzeilen, Hinweise in Grau und Buttons mit weißer Schrift auf hellem Grund. Im Dark Mode kehren viele Clients die Farben teilweise um, deshalb sollten Sie den Kontrast in beiden Darstellungen prüfen.

Farbe nie als einzige Information

Eine Fehlermeldung, die nur rot ist, erreicht Menschen mit Farbfehlsichtigkeit nicht. Ergänzen Sie Farbe immer um Symbol oder Text:

<!-- Schlecht: nur Farbe -->
<span style="color: red;">Fehler</span>

<!-- Besser: Farbe plus Text -->
<span style="color: red;">⚠ Fehler: ungültige E-Mail-Adresse</span>

Links, Buttons und Fokus

Screenreader-Nutzer lassen sich eine Liste aller Links einer Seite anzeigen. Stehen dort nur Einträge wie „hier klicken“, ist die Liste nutzlos. Der Linktext muss das Ziel beschreiben.

<!-- Schlecht -->
<a href="...">Hier klicken</a>

<!-- Gut -->
<a href="...">Bestelldetails ansehen</a>

<!-- Gut -->
<a href="...">Jahresbericht 2026 herunterladen (PDF, 2 MB)</a>

Bei wiederholten Buttons wie „Mehr erfahren“ in drei Produktkarten hilft ein verborgener Zusatztext, der das Produkt benennt. Mail-Clients unterstützen verborgene Texte unterschiedlich gut. Testen Sie das Ergebnis deshalb im Zielclient.

Fokus-Zustände

Tastaturnutzer brauchen einen sichtbaren Fokus. In E-Mails ist das schwierig, weil viele Clients keine Fokus-Stile übernehmen. Ein Versuch ist ein Outline-Stil am Link. Behandeln Sie ihn als Zusatz und nicht als Garantie:

<a href="..." style="outline: 2px solid #1d4ed8;">
  Linktext
</a>

Sprache und Schriftgröße

Deklarieren Sie die Sprache des Dokuments. Für eine deutsche Mail steht lang="de" im html-Element. Enthält die Mail einzelne Passagen in einer anderen Sprache, markieren Sie diese Stellen gesondert:

<p>Das französische Wort <span lang="fr">bonjour</span> heißt Guten Tag.</p>

Für Fließtext empfehlen sich mindestens 14 px, besser 16 px. Eine Zeilenhöhe von 1,4 bis 1,6 macht den Text für Menschen mit Leseschwäche deutlich angenehmer. Vermeiden Sie Text in Bildern, weil er sich nicht skalieren lässt, und setzen Sie Inhalte so, dass sie bei zoom auf 200 % nicht abgeschnitten werden.

Testen mit Screenreadern und Prüfwerkzeugen

Automatische Prüfungen sind ein guter erster Schritt, ersetzen aber das Hören nicht. Ein Hörtest mit einem Screenreader zeigt, ob die Reihenfolge stimmt und ob die Mail verständlich ist. Die gängigen Werkzeuge sind:

• VoiceOver auf macOS und iOS, über Cmd+F5 aktivierbar
• NVDA unter Windows, kostenlos und weit verbreitet
• JAWS unter Windows, kostenpflichtig und in vielen Unternehmen Standard

Hören Sie sich die Mail einmal komplett an und fragen Sie: Ist die Gliederung klar? Werden Bilder sinnvoll beschrieben? Ergeben die Links ohne Kontext einen Sinn? Notieren Sie jeden Punkt, an dem Sie stocken, und korrigieren Sie ihn im Template, nicht erst in der fertigen Mail.

Automatisierte Prüfer wie der Barrierefreiheitstest von Email on Acid finden fehlende Alt-Texte und Kontrastprobleme schnell. Lassen Sie sie in jedem Durchlauf laufen und behandeln Sie ihre Meldungen als Pflicht, nicht als Empfehlung.

Entscheidungstabelle: welches Werkzeug zu welchem Team passt

Die folgende Tabelle ordnet typische Situationen einem Werkzeug zu. Sie ist eine Orientierung für die Shortlist und kein Ersatz für einen Test mit Ihren eigenen Vorlagen.

Einrichtung und Übergabe

Ein Werkzeug entfaltet seinen Nutzen erst mit einem klaren Ablauf. Die folgende Checkliste ordnet die Einrichtung in vier Schritte. Jeder Schritt endet mit einer Prüfung, die sich dokumentieren lässt.

Der letzte Punkt wird häufig vergessen. Viele Versanddienste verändern den HTML-Code beim Import, etwa durch Linkumschreibung oder das Entfernen von Attributen. Prüfen Sie deshalb nach dem ersten Versand an Ihr eigenes Testkonto, ob role, Alt-Text und Überschriften noch vorhanden sind. Das gilt für jede Versandplattform, die Sie mit einem Builder kombinieren.

So wählen Sie aus

Wählen Sie nicht nach Funktionsliste, sondern nach einem Testlauf mit einer echten Vorlage. Nehmen Sie eine Mail, die Ihr Team typischerweise verschickt, mit dynamischen Inhalten, wiederverwendeten Modulen und einem Bild-Button. Bauen Sie genau diese Mail mit höchstens drei Kandidaten nach. Zwei davon pilotieren Sie, einer bleibt Reserve.

Danach zählen Sie vier Dinge: wie viele Schritte bis zur Freigabe nötig sind, wie oft ein Fehler bei Alt-Text oder Überschriften passiert, wie das Ergebnis im Dark Mode aussieht und was der nächste Tarif kostet. Notieren Sie diese Zahlen schriftlich, bevor Sie entscheiden.

Ein Wechsel lohnt sich, wenn dieselbe Art von Fehler dreimal nacheinander nur in einem Werkzeug auftritt oder wenn der nächste Tarif mehr kostet als der ganze Pilot. In allen anderen Fällen ist ein sauber dokumentierter Pilot billiger als eine Migration mitten im Quartal.

Häufige Fragen

Macht ein barrierefreier Builder meine Mails automatisch barrierefrei?

Nein. Ein Builder kann Grundlagen wie Tabellen-Markup und Pflichtfelder für Alt-Text bereitstellen. Die Inhalte, die Gliederung und die Entscheidung, ob ein Bild dekorativ ist, bleiben bei Ihnen. Ohne Prüfschritt bleibt die Verantwortung unbeantwortet.

Reicht ein automatischer Barrierefreiheitstest?

Er findet häufige technische Fehler wie fehlende Alt-Texte oder zu schwache Kontraste. Er kann nicht beurteilen, ob ein Alt-Text sinnvoll ist oder ob die Reihenfolge beim Vorlesen verständlich klingt. Ergänzen Sie ihn deshalb um einen Hörtest mit einem Screenreader.

Welches Werkzeug ist für Entwickler am besten?

Das hängt vom Stack ab. Ein Team mit React findet in React Email den kürzesten Weg. Ein Team, das Komponenten in einem eigenen Framework pflegt, kommt mit MJML zurecht. Maizzle passt, wenn Utility-CSS und ein Build-Schritt bereits Standard sind. In allen drei Fällen müssen Alt-Texte und Überschriften im Template gepflegt werden.

Wie wichtig ist role="presentation" wirklich?

Es verhindert, dass Screenreader Layout-Tabellen wie Datentabellen ankündigen. Für Leser ohne Screenreader ist es unsichtbar, für Nutzer mit Hilfstechnologie macht es einen spürbaren Unterschied. Setzen Sie es auf jeder Layout-Tabelle und prüfen Sie es im Ausgabecode.

Kann ich Vorlagen aus einem visuellen Editor später nachbessern?

Ja, wenn der Export den Code lesbar lässt. Prüfen Sie nach dem Export Überschriften, Alt-Texte und Linktexte und korrigieren Sie sie im Template. Achten Sie darauf, dass spätere Änderungen im Editor die Korrekturen nicht überschreiben.

Muss ich für jeden Versand neu prüfen?

Nicht jeden Versand vollständig, aber jede neue Vorlage und jede größere Änderung am Layout. Bei reinen Textänderungen genügt eine kurze Prüfung von Alt-Texten und Linktexten. Dokumentieren Sie den Ablauf, damit die Prüfung nicht von einer einzelnen Person abhängt.

Was bedeuten die Preisangaben für kleine Teams?

Für Email on Acid liegt der Einstieg bei 99 US$ pro Monat, also 1.188 US$ im Jahr bei monatlicher Abrechnung über 12 Monate. Für die Framework- und Editor-Werkzeuge nennt die Preisangabe keine festen Beträge; fragen Sie den Anbieter nach einem Angebot, bevor Sie einen Pilot planen.