Sie lieben HTML-E-Mails, nicht wahr?
Als Entwickler, wahrscheinlich nicht… aber Abonnenten absolut. Sie verschlingen sie, konsumieren sie auf jedem erdenklichen Gerät und generieren verdammt viel Umsatz für Unternehmen, die ihr E-Mail-Marketing ernst nehmen.
Aber die meisten Webentwickler, die mit dem Erstellen von HTML-E-Mails beauftragt sind, wollen sie einfach so schnell wie möglich fertigstellen und sich wichtigeren Aufgaben widmen. Trotz des anhaltenden Werts von E-Mails für Abonnenten, straffen Zeitpläne und eine allgemeine Abneigung gegen die Arbeit führen dazu, dass Dinge auf der Strecke bleiben; und, genau wie in der Web-Welt, ist Barrierefreiheit eines der ersten Dinge, die bei E-Mails beiseitegelegt werden.
Ich denke, wir sind uns alle einig, dass Barrierefreiheit ein wichtiges Thema ist. Leider wird es in der Welt des E-Mail-Marketings noch mehr ignoriert als im Web.
Barrierefreiheit in E-Mails muss jedoch nicht viel Zeit in Anspruch nehmen. Es gibt ein paar einfache Praktiken, die Sie in Ihre eigenen Kampagnen integrieren können, um Ihre E-Mails zugänglicher und Ihre Abonnenten noch glücklicher zu machen.
Zugängliche Tabellen?
Einer der Hauptgründe, warum Webentwickler das Erstellen von E-Mails hassen, ist, dass wir für das Layout in E-Mails immer noch Tabellen verwenden müssen. Obwohl es einige unterschiedliche Möglichkeiten gibt, HTML-Tabellen zu umgehen, verlassen sich die meisten E-Mails immer noch darauf, um sicherzustellen, dass sie in Microsoft Outlook gut aussehen, das keine traditionellere CSS-Positionierung unterstützt, geschweige denn neuere CSS-Layouttechniken wie Grid (obwohl das auch in E-Mails möglich ist).
Aber HTML-Tabellen stellen eine Hürde für Benutzer dar, die sich für die Konsumierung ihrer E-Mails auf Screenreader verlassen. Dies wird deutlich, wenn man die Ausgabe eines Screenreaders hört, der eine typische HTML-E-Mail-Kampagne durcharbeitet. Mark Robbins von Rebel hat vor einiger Zeit ein ausgezeichnetes Beispiel für dieses Verhalten veröffentlicht.
Der Screenreader macht seine Arbeit: Er sieht eine Tabelle, geht davon aus, dass sie tabellarische Daten enthält, und liest sie entsprechend vor.
Da wir Tabellen jedoch rein für strukturelle Zwecke verwenden, müssen Screenreader diese Tabellen ignorieren. Hier können ARIA-Rollen uns helfen. Durch die Anwendung des Attributs role="presentation" auf eine Tabelle können wir den Screenreader anweisen, diese Elemente zu überspringen und direkt zum Inhalt zu springen.
Sehen Sie den Pen Accessible Emails – Tables ARIA Presentation von Jason Rodriguez (@rodriguezcommaj) auf CodePen.
Mit dieser einen einfachen Ergänzung sind unsere E-Mails viel zugänglicher. Es ist zu beachten, dass verschachtelte Tabellen dieses Verhalten nicht erben, sodass Sie role="presentation" individuell auf jede Tabelle in Ihrer Kampagne anwenden müssen. Das Erstellen eines Snippets oder das Integrieren in Ihren E-Mail-Boilerplate ist eine gute Möglichkeit, die Barrierefreiheit sicherzustellen, ohne darüber nachdenken zu müssen.
Aus dem Bild und hinein in den Code
Eine gängige Praxis im E-Mail-Marketing ist die Verwendung von Bildern für alles in der E-Mail: Grafiken, Illustrationen, Text, Links und Schaltflächen. Dies mag zwar effizient sein (aufschneiden, zerteilen und versenden), ist aber ein weiteres großes Problem für Abonnenten, die auf Screenreader angewiesen sind. Die typische bildbasierte E-Mail enthält viel an Informationen, die von einer Maschine nicht verarbeitet werden können. Darüber hinaus deaktivieren viele E-Mail-Clients Bilder standardmäßig. Haben Sie jemals so etwas gesehen?

Wir wollen Situationen vermeiden oder verbessern, in denen Inhalte für Benutzer nicht sichtbar oder für einen Screenreader nicht lesbar sind. Dafür gibt es zwei Möglichkeiten.
Das Erste ist, sich weniger auf Bilder und mehr auf HTML zu verlassen, um Ihre Botschaft zu vermitteln. Holen Sie Texte aus Ihren Bildern heraus und fügen Sie sie als echten, lebendigen Text in Ihre E-Mail ein.

HTML-Text ist nicht anfällig für Bildblockierung in E-Mail-Clients, daher wird er immer angezeigt. Darüber hinaus kann der meiste Text, der typischerweise in einer E-Mail enthalten ist, in HTML-Text umgewandelt werden. Sie können diesen Text beliebig formatieren, sogar mit Web-Schriften, und Ihre Inhalte sind für Benutzer sichtbar und für Screenreader verständlich.
Dies ist besonders wichtig, wenn es um Links und Schaltflächen in E-Mails geht. Viele Designer verlassen sich auf Bilder für Schaltflächen, da sie diese beliebig gestalten können. Diese bildbasierten Schaltflächen sind jedoch genauso von dem Bildblockierungsverhalten betroffen wie jedes andere Bild. Mit HTML, CSS und in einigen Fällen Microsofts proprietärer VML-Sprache können Sie codebasierte Schaltflächen erstellen, die überall angezeigt werden und dennoch zu Ihrem Design passen.
Sehen Sie den Pen Accessible Emails – Bulletproof Buttons von Jason Rodriguez (@rodriguezcommaj) auf CodePen.
Das Zweite ist, sich auf Alternativtexte für Bilder zu verlassen. Durch das Hinzufügen des Attributs alt können wir den Inhalt von Bildern für Screenreader beschreiben, damit Benutzer einen Kontext und ein besseres Verständnis der E-Mail erhalten.
Die gleichen Regeln gelten in E-Mails wie im Web
- Alle Bilder sollten ein Attribut
althaben - Alternativtexte sollten den Inhalt und die Funktion eines Bildes wiedergeben
- Alternativtexte sollten niemals redundant sein
- Alternativtexte verlassen sich stark auf den Kontext, der durch den umgebenden Inhalt eines Bildes bereitgestellt wird
- Dekorative Bilder sollten ein leeres Attribut
altverwenden
Ein einfaches Beispiel für Alternativtext in einer E-Mail wäre für etwas wie einen Einzelhandelsverkauf.
Sehen Sie den Pen Accessible Emails – Styled ALT Text von Jason Rodriguez (@rodriguezcommaj) auf CodePen.
Zusätzlich zur Verbesserung der Barrierefreiheit unserer E-Mails können wir diesen Alternativtext sogar so formatieren, dass er sich besser in das restliche E-Mail-Design einfügt, wenn Bilder deaktiviert sind. Mit Dingen wie color, font-family, font-size, font-weight und line-height können Sie Alternativtext weitgehend genauso formatieren wie jeden anderen Text in der E-Mail. In Kombination mit etwas wie background-color für das Bild machen diese Stile es möglich, hochoptimierte – und zugängliche – E-Mails zu haben, wenn Bilder deaktiviert sind.

Alles eine Frage der Semantik
Trotz dessen, was manche E-Mail-Marketer und Entwickler Ihnen erzählen werden, ist Semantik in E-Mails doch wichtig. Sie bietet nicht nur zugängliche Haken zur Navigation durch eine E-Mail, sondern kann auch Fallback-Stile liefern, die helfen, die Hierarchie von E-Mails in dem bedauerlichen Fall aufrechtzuerhalten, dass CSS nicht geladen oder unterstützt wird.
Früher wurde die gesamte Textformatierung auf Tabellenzellen innerhalb einer Kampagne vorgenommen, wobei jeder Text ein direktes Kind dieser Tabellenzelle war.
Sehen Sie den Pen Accessible Emails – Old Text Approach von Jason Rodriguez (@rodriguezcommaj) auf CodePen.
E-Mail-Entwickler vermieden die Verwendung semantischer Elemente wie Überschriften und Absätze, da E-Mail-Clients ihre eigenen Standardstile für diese Elemente (korrekterweise) anzeigten, was manchmal zu fehlerhaften Layouts oder unbeabsichtigten Designs führte. Ich weiß nicht, ob es reine Faulheit oder etwas anderes war, aber nur sehr wenige Entwickler nutzten semantische Elemente mit einfachen Überschreibungen, um ihre Designs zugänglich und konsistent über verschiedene Clients hinweg zu halten.
Das Hinzufügen der margin-Eigenschaft zu Block-Level-semantischen Elementen – und das Verlassen auf die Stilvererbung von der Tabellenzelle – kann zugänglichere E-Mails erstellen, die fast überall korrekt angezeigt werden.
Sehen Sie den Pen Accessible Emails – Semantic Text Approach von Jason Rodriguez (@rodriguezcommaj) auf CodePen.
Sie müssen auch nicht bei einfachen Überschriften oder Absätzen aufhören. Sie können Abschnittselemente wie main, header, footer, article und mehr verwenden, um Ihren E-Mails zusätzlichen semantischen Wert zu verleihen. Ich möchte Sie jedoch warnen, sie zusätzlich zu Ihrer bestehenden tabellenbasierten Struktur zu verwenden. Nicht alle E-Mail-Clients unterstützen das Anwenden von Stilen auf diese Elemente, daher ist etwas wie das hier ein guter Ansatz
Sehen Sie den Pen Accessible Emails – Semantic Article von Jason Rodriguez (@rodriguezcommaj) auf CodePen.
Gestaltung für Abonnenten
Die letzte Technik, die ich besprechen möchte – obwohl nicht die letzte verfügbare Technik – ist die Einhaltung bewährter Designprinzipien in unseren Kampagnen, um sie zugänglich zu halten.
Barrierefreiheit hat nicht nur mit Screenreadern zu tun. Abonnenten können Sehbehinderungen sowie körperliche oder kognitive Einschränkungen haben, die den Konsum von E-Mails erschweren, insbesondere wenn das Design einer E-Mail seit Jahren nicht aktualisiert wurde. Indem wir uns auf Designprinzipien wie Hierarchie, Raum, Muster, Nähe, Schriftgröße und Kontrast verlassen, können wir sicherstellen, dass ein breites Spektrum von Abonnenten unsere E-Mail-Kampagnen verstehen und genießen kann.
Dies zeigt sich besonders, wenn E-Mails auf mobilen Geräten betrachtet werden. Wenn Sie die mobile Ansicht von Anfang an nicht berücksichtigen oder Responsive E-Mail-Design verwenden, können Ihre Desktop-First-E-Mail-Kampagnen auf den meisten mobilen E-Mail-Clients mühsam zu bedienen sein, wenn sie skaliert werden.

Allein die Überprüfung Ihrer Designs unter Berücksichtigung mobiler und beeinträchtigter Benutzer kann viel dazu beitragen, Ihre E-Mails zugänglich zu halten. Die Verwendung größerer Schriftarten, die für eine Vielzahl von Benutzern lesbar sind, kombiniert mit ordnungsgemäßen Überschriftenstilen und einer leicht zu scannenden Hierarchie, ist eine großartige Grundlage. Das Hinzufügen von wiederholbaren Mustern in Ihren E-Mails, die das Scannen und Verstehen weiter erleichtern, zusammen mit viel Weißraum und richtig kontrastierenden Farben, bringt Ihre E-Mails noch weiter.
Ich ermutige Sie, Tools wie Chrome Lighthouse und Accessible-Colors.com zu verwenden, um die Barrierefreiheit Ihrer HTML-E-Mail-Designs zu überprüfen. Es handelt sich alles um HTML und CSS, daher funktionieren die gleichen Tools im E-Mail-Bereich wie im Web. Nutzen Sie sie!
Haben Sie eigene Tipps?
Obwohl vieles in der E-Mail-Entwicklung im alten Korsett steckt, heißt das nicht, dass wir unsere Kampagnen nicht zusammen mit unseren Websites modernisieren können. Viele dieser Tipps können direkt in Ihren E-Mail-Boilerplate oder Code-Schnipsel integriert werden, sodass Sie zugänglichere HTML-E-Mails erstellen können, ohne zu viel darüber nachdenken zu müssen.
Lassen Sie sich gleichzeitig nicht davon abhalten, Ihre E-Mails mit zusätzlicher Sorgfalt zu gestalten. Dieser Artikel kratzt nur an der Oberfläche dessen, was in der HTML-E-Mail-Entwicklung möglich ist. Ich würde mich freuen, Ihre Tipps zum Erstellen zugänglicher E-Mails in den Kommentaren unten zu hören.
Toller Artikel! Ich hasse das Erstellen von Newslettern, aber ich liebe es, sie zu lesen.
Aus diesem Grund und in einem halb verwandten Zusammenhang (Entschuldigung, falls das vom Thema abweicht/nicht erlaubt ist), erstelle ich gerade ein Newsletter-Verzeichnis, das es Benutzern ermöglicht, Newsletter zu durchsuchen und zu finden, für die sie sich anmelden können. Eine Beta-Version finden Sie hier: https://lettrs.email/
Nochmal vielen Dank für den Artikel! Es ist immer gut, neue Artikel, Meinungen und Ansichten zu bestehenden Technologien und Problemen zu sehen!
Ganz am Anfang bekräftigen Sie
– Abonnenten verschlingen HTML-E-Mails
– HTML-E-Mails stecken in Tabellen fest
Manche Leute sind anderer Meinung. „Studien“ über HTML-E-Mails werden oft von Mailchimp gesponsert (bald von Oracle übernommen…).
Bitte schauen Sie sich (in derselben Reihenfolge) an
– https://www.gkogan.co/blog/dont-design-emails/
– https://litmus.com/blog/a-bulletproof-guide-to-using-html5-and-css3-in-email
Es ist 2017, Mann!
Inline SVG
Danke für diesen Beitrag, das ist ein gutes Thema, um es im Zusammenhang mit CSS zu diskutieren. Viele E-Mail-Anbieter haben spezifische Limits für die Stile, die sie zulassen oder entfernen. Und Gmail entfernt SVG-Bilder komplett. (Stand meines Wissens)
Mein einziger Punkt ist, warum überhaupt Tabellen verwenden? Ich sehe keinen Wert in der Verwendung einer Tabelle. Wenn es eine mobile E-Mail ist, brauchen Sie keine Spalten. Wenn nicht, haben Sie andere Layout-Stile, die Sie für Spalten verwenden können. Und Spalten sind das Einzige, womit Tabellen geholfen haben.
Margin: 0 auto; mit einer max-width bringt Ihnen eine zentrierte Spalte in Ihrem Layout. Viel Spaß beim Codieren, freue mich auf die Kommentare, die hier erscheinen werden.
Hallo Vanderson,
Die Outlook-Desktop-App unter Windows und Windows Mail 10 verwenden beide Microsoft Word zum Rendern von HTML (ich weiß, verrückt, oder?) und leider unterstützt dies
margin: 0 auto; mit max-widthnicht, sodass wir gezwungen sind, Tabellen für Dinge zu verwenden wie: Beschränkung der Breite, Verwendung mehrerer Spalten oder Anwenden eines Hintergrunds.Derzeit haben diese Clients einen Marktanteil von etwa 8%, daher ist es immer noch genug, worüber man sich Sorgen machen muss, obwohl Sie Ihre eigenen Analysen überprüfen sollten, um zu sehen, ob es für Sie relevant ist.
Jason hat auf seinen Artikel über die Verwendung von bedingten „Geister“-Tabellen für MSO verwiesen
https://www.rodriguezcommaj.com/blog/nearly-table-free-emails
Und mein Artikel über ein laufendes Projekt, das MS Word dazu bringt, ein
<div>in ein<table>umzuwandelnhttp://blog.gorebel.com/get-off-the-table/
Bezüglich VML-Buttons: Sie müssen
o:PixelsPerIncheinstellen, sonst wird der Button auf hochauflösenden Displays verunstaltet. Siehe https://stackoverflow.com/questions/31860828/prevent-images-in-html-email-scaling-up-with-dpi-scaling-outlook-2013/31864815#31864815; Sie möchten etwas wie das hierDie Beschreibung von VML als „Microsofts proprietäre VML-Sprache“ ist nicht ganz korrekt; siehe seine Geschichte auf Wikipedia: VML war ein Vorläufer von SVG und wurde damals von einer Reihe von Unternehmen unterstützt. Es ist im normalen Web jetzt völlig tot; nur weil Microsoft sich auf die Verwendung des Word-HTML-Renderers/Editors (der schlimmer ist als IE 5) in Outlook 2007 zurückentwickelt hat, lebt VML überhaupt noch. Und wir alle wünschen uns, dass sie diese alberne Entscheidung korrigieren, die so vielen Leuten so riesige Geldsummen gekostet hat.
Vergessen Sie auch nicht, eine Klartextversion Ihrer E-Mail zu unterstützen.
Einige Tipps zu Klartext-E-Mails: https://litmus.com/blog/best-practices-for-plain-text-emails-a-look-at-why-theyre-important
Eine Klartext-E-Mail macht den Inhalt Ihrer E-Mail noch zugänglicher.
Ein weiteres Problem, das auftreten kann, ist das, was mit E-Mail-Clients passiert, die HTML blockieren, was ebenfalls vorkommt!
Es ist eine Weile her, seit ich E-Mails gemacht habe, aber als ich es tat, benutzte ich Mailchimps eigenen Builder, Zurb Ink oder baute von Grund auf. Erstens habe ich nie verstanden, wie Anleitungen sagen würden, wenn Ihr Publikum X benutzt, können Sie nie wirklich wissen, in was die E-Mail geöffnet wird, also müssen Sie entweder für den kleinsten gemeinsamen Nenner gestalten oder Fallbacks anbieten. Und meiner Erfahrung nach haben Sie Budget- und Zeitbeschränkungen, die Uhr tickt. Sie werden denken, Sie haben es gemeistert und dann im letzten Moment beim Testen feststellen, dass die E-Mails fehlschlagen, normalerweise in Outlook. Also weiß ich, dass es technologisch sehr fantasielos ist, aber durch die Reduzierung der Technologiepalette fördert es die Kreativität. Am Ende bin ich bei einer einzigen Spalte, ein paar Bildern, Text geblieben. Die Endergebnisse waren genauso gut wie die komplexeren Mehrspaltenlayouts, der Kunde war zufrieden, es funktionierte und dauerte jedes Mal viel weniger Zeit für die Entwicklung. Besonders sobald Sie eine Vorlage haben, ändern Sie die Bilder, ändern Sie den Text, fertig, senden, Rechnung.
Großartige Sachen. Als jemand, der täglich mit HTML-E-Mails zu tun hat (für einen Vertrag), schätze ich den Artikel und die Kommentare aller.
Mein Senf dazu wäre: Fügen Sie alle -mso-Stile in bedingte Kommentare ein, wie <!–[if mso]> (nach Ihrem Geschmack, mit Versionsnummern, wenn Sie denken, dass Sie müssen). Getrennt von den restlichen Deklarationen.
Warum? Auf diese Weise wird Ihr CSS immer noch validiert und wird nicht automatisch ignoriert und verworfen von diesen lästigen E-Mail-Clients, die so etwas tun (hier blicke ich Sie an, Gmail in bestimmten Browsern und auf bestimmten Betriebssystemen). Was passiert? Wenn Sie ungültiges CSS haben (wie von bestimmten E-Mail-Clients bestimmt), werden sie Ihren Abschnitt entfernen. Kein Problem, sagen Sie: „Ich verwende ohnehin Inline-CSS-Stile im Text.“ Das ist gut, aber wenn Sie gültiges (validierendes) CSS erstellen können, warum sollten Sie es nicht tun?
Nach meinem besten Wissen.