HTML-E-Mail bleibt HTML, das von einem Benutzeragenten gerendert wird — ein Webmail-Client ist ein Browser, und die Rendering-Engine einer nativen Mail-App unterscheidet sich nicht grundlegend davon. Die WCAG-Erfolgskriterien sehen keine E-Mail-spezifische Ausnahme vor und gelten für eine reine CSS-Abstimmung, ein Quiz oder ein Akkordeon genauso direkt wie für die entsprechende Webkomponente. Dies ist eine praktische Checkliste für die vier Kriterien, die für interaktive, auf dem Checkbox-Hack basierende E-Mails am wichtigsten sind.
Warum WCAG hier überhaupt gilt
WCAG 2.2 spricht von „Inhalten“, die von einem „Benutzeragenten“ gerendert werden, und nicht ausdrücklich von „Webseiten“ — es handelt sich nicht um einen formalen, E-Mail-spezifischen Standard, da E-Mail als Medium in der Spezifikation überhaupt nicht genannt wird. Der zugrunde liegende Inhalt ist jedoch in beiden Fällen HTML. Deshalb betrachtet die Fachwelt für Barrierefreiheit die WCAG-Erfolgskriterien als praktischen Maßstab für E-Mail-Inhalte, ebenso wie diese Checkliste, statt E-Mail als getrennte Kategorie zu behandeln, die von den Richtlinien nicht erfasst wird.
1.1.1 Nicht-Text-Inhalt — jedes Bild braucht einen echten Alternativtext
Produktfotos, Hero-Bilder, dekorative Trennelemente und reine Icon-Schaltflächen benötigen alle ein alt-Attribut, das ein Screenreader vorlesen kann — oder bei wirklich dekorativen Bildern ohne Informationsgehalt ein ausdrücklich leeres alt="", damit der Screenreader sie überspringt, statt einen bedeutungslosen Dateinamen vorzulesen. Bei interaktiven Blöcken ist das noch wichtiger als bei statischen: Ein Glücksrad oder eine Rubbelkarten-Enthüllung, die vollständig bildgesteuert ist und keine Textalternative zur Beschreibung des Ergebnisses bietet, lässt einen Screenreader-Nutzer nicht erkennen, was er gewonnen hat.
1.4.3 / 1.4.11 — Kontrast für Text und interaktive Steuerelemente
WCAG legt für normalen Fließtext ein Mindestkontrastverhältnis von 4.5:1 fest (3:1 für großen Text gemäß 1.4.3) und für die sichtbaren Begrenzungen von UI-Komponenten und Grafiken mindestens 3:1 (1.4.11). Beides gilt direkt für interaktive Elemente und nicht nur für Absatztext — für die Umrandung einer Abstimmungsoption, den Hintergrund einer Quizantwort-Schaltfläche im Verhältnis zu ihrem Container oder die Ziffern eines Countdown-Timers vor seinem Hintergrund. Ein interaktives Steuerelement mit geringem Kontrast ist nicht nur ein ästhetischer Fehler; für einen sehbehinderten Empfänger kann es vollständig unsichtbar sein.
2.1.1 Tastatur — der echte Vorteil der Checkbox-Hack-Technik
Ein echtes <input type="radio">/<input type="checkbox"> zusammen mit einem <label for="..."> kann in jedem Client, der Formularsteuerelemente überhaupt rendert, nativ fokussiert und mit Tab plus Leertaste oder Eingabetaste bedient werden — ohne zusätzliches Markup oder zusätzliche Arbeit, denn so behandeln Browser echte Formularsteuerelemente schon immer. Unter CSS-:checked-Zustandsautomaten erfahren Sie, wie die Technik selbst funktioniert. Das ist ein echter Vorteil gegenüber dem typischen Verhalten eines JavaScript-gesteuerten Webkarussells — ein <div onclick> ohne Tastatur-Handler — und ein Vorteil, den interaktive E-Mails konstruktionsbedingt statt durch Zusatzaufwand erhalten, solange echte <label>-/<input>-Paare statt bloßer anklickbarer <div>-Elemente verwendet werden.
2.5.8 Zielgröße (Minimum) — neu in WCAG 2.2
Erfolgskriterium 2.5.8, eingeführt in WCAG 2.2, legt für interaktive Ziele eine Mindestgröße von 24×24 CSS-Pixeln fest, mit Ausnahmen für Inline-Text, wesentliche Layoutbeschränkungen oder ein an anderer Stelle verfügbares gleichwertiges größeres Steuerelement. Besonders relevant ist dies auf Mobilgeräten — auf denen die meisten E-Mail-Öffnungen stattfinden — für die kleinsten interaktiven Elemente, die sich in einem Studio leicht zu stark verkleinern lassen: Karussellpunkte, Symbole für Sternebewertungen und dicht beieinanderliegende Quizantwort-Chips.
4.1.2 Name, Rolle, Wert — :checked-Steuerelemente richtig beschriften
Ein Screenreader liest Name, Rolle und aktuellen Zustand eines Steuerelements aus echtem semantischem Markup vor — genau das stellt ein <label> um ein echtes <input> ohne weiteren Aufwand bereit, und genau das fehlt bei einem bloßen formatierten <div>, das eine Schaltfläche ersetzt. In der Praxis bedeutet das, dass jede Abstimmungsoption, Quizantwort und Akkordeon-Überschrift echten Beschriftungstext braucht, den ein Screenreader vorlesen kann, statt nur eines Hintergrundbilds oder Icons ohne begleitenden Text.
Praktische Checkliste
- Jedes Bild besitzt ein echtes
altoder ein ausdrücklich leeresalt="", wenn es dekorativ ist. - Text und Umrandungen interaktiver Steuerelemente erfüllen einen Kontrast von 4.5:1 (Text) / 3:1 (UI-Komponente).
- Jede
:checked-Interaktion verwendet ein echtes Paar aus<input>+<label for="...">— niemals ein bloßes anklickbares<div>. - Interaktive Ziele sind mindestens 24×24 CSS-Pixel groß, insbesondere bei mobil ausgerichteten Blöcken.
- Beschriftungen von Abstimmungen, Quizzen und Akkordeons enthalten echten, lesbaren Text — nicht nur ein Bild oder Icon.