Dostępność e-maili: inkluzywne wiadomości HTML

Dla większości organizacji e-mail to najczęstszy punkt kontaktu z klientami. Potwierdzenie zamówienia, reset hasła, miesięczne zestawienie, newsletter — te wiadomości często docierają na długo przed tym, zanim ktoś odwiedzi Twoją stronę, i docierają znacznie częściej. A jednak dostępność e-maili to jeden z najbardziej pomijanych zakątków cyfrowej inkluzji. Zespoły, które dużo inwestują w dostępną stronę, rutynowo wysyłają kampanie zbudowane na zagmatwanym znaczniku, treści złożonej wyłącznie z obrazów i przyciskach, które czytnik ekranu odczytuje jako „kliknij tutaj”.

Powód jest po części historyczny, a po części techniczny: e-mail HTML to osobna dyscyplina, z własnymi ograniczeniami, własnymi silnikami renderującymi i własnymi trybami awarii. Techniki, które w nowoczesnym webie są oczywiste — semantyczne punkty orientacyjne, układy flexbox, niestandardowe właściwości CSS — są zawodne lub wręcz niedziałające w macierzy klientów pocztowych. Uczynienie e-maila dostępnym to nie to samo zadanie co uczynienie dostępną strony internetowej, a traktowanie ich jako identycznych jest dokładnie powodem, dla którego tak wiele e-maili zawodzi.

Ten przewodnik omawia, czego dostępność e-maili faktycznie wymaga: jak strukturyzować znacznik, aby technologia wspomagająca mogła go przetworzyć, jak obsługiwać tabele prezentacyjne, na których wciąż opiera się układ e-maili, jak pisać tekst alternatywny i linki, które mają sens poza kontekstem, jak przetrwać tryb ciemny i powiększenie oraz jak testować rezultat w Outlook, Gmail, Apple Mail i czytnikach ekranu. Jeśli wolisz, by zrobili to dla Twoich szablonów specjaliści, nasza usługa remediacji e-maili obejmuje cały stos.

Dlaczego e-mail HTML to osobna dyscyplina

Strona internetowa renderuje się w przeglądarce. Istnieje garstka popularnych przeglądarek, aktualizują się one według przewidywalnych harmonogramów i zbliżają się do standardów webowych. E-mail jest przeciwieństwem. Twoja wiadomość może zostać otwarta w dziesiątkach klientów — Outlook w systemie Windows, Outlook w sieci, nowy Outlook, Gmail w przeglądarce, aplikacja Gmail, Apple Mail w macOS i iOS, Yahoo, Samsung Email i wiele innych — każdy z innym silnikiem renderującym i innym, często kurczącym się, podzbiorem obsługiwanego HTML i CSS.

Najbardziej znanym przykładem jest desktopowy Outlook w systemie Windows, który historycznie renderował e-maile za pomocą silnika Microsoft Word, a nie prawdziwego silnika przeglądarki. Już samo to zmusza twórców e-maili do powrotu do układów opartych na tabelach, stylów inline i defensywnych wzorców, które web porzucił lata temu. Wielu klientów usuwa też bloki <style>, odrzuca nowoczesny CSS i przepisuje atrybuty, które uznaje za niebezpieczne.

Dla dostępności ma to ogromne znaczenie. Semantyczny HTML, na którym polegasz w przypadku strony — <nav>, <main>, punkty orientacyjne ARIA — jest w e-mailu często usuwany lub ignorowany. Nie możesz oprzeć się na jednym celu renderowania. Dostępność e-maili polega zatem na budowaniu wiadomości, które degradują się z gracją: pozostają czytelne, nawigowalne i sensowne nawet wtedy, gdy układ się załamuje, obrazy się nie ładują lub style zostają odrzucone. To defensywne podejście jest fundamentem, na którym opiera się wszystko inne w tym przewodniku, i jest powodem, dla którego e-mail należy do dedykowanego programu usług dostępności, a nie do włączenia w ogólną pracę webową.

Struktura semantyczna i logiczna kolejność odczytu

Nawet przy wszystkich ograniczeniach najcenniejszą rzeczą, jaką możesz zrobić dla użytkownika czytnika ekranu, jest nadanie e-mailowi jasnej, liniowej struktury. Czytniki ekranu odczytują treść w kolejności DOM, więc kolejność Twojego znacznika jest kolejnością, w jakiej słychać Twoją wiadomość. Jeśli Twój projekt umieszcza baner promocyjny przed właściwą wiadomością, baner zostaje ogłoszony jako pierwszy — niezależnie od tego, jak wygląda układ.

Używaj prawdziwych elementów nagłówków, aby ustalić hierarchię. E-mail powinien mieć jeden logiczny nagłówek najwyższego poziomu (zwykle główny temat lub ofertę) jako <h1>, a kolejne sekcje oznaczone jako <h2> i <h3>. Użytkownicy czytników ekranu nawigują po nagłówkach, by przeglądać wiadomość, więc dobrze ustrukturyzowany konspekt zamienia ścianę tekstu w coś, co da się przejrzeć. Nie udawaj nagłówków dużym, pogrubionym tekstem <span>; wizualnie może to wyglądać jak nagłówek, ale technologia wspomagająca słyszy zwykły tekst główny. Podobnie używaj prawdziwego znacznika listy (<ul>, <ol>, <li>) dla list i ustaw język dokumentu atrybutem lang na elemencie <html>, aby czytniki ekranu używały poprawnej wymowy i głosu.

Kolejność odczytu również musi mieć sens sama w sobie. Przeczytaj swój znacznik z góry na dół, ignorując całą stylizację, i zadaj sobie pytanie, czy nadal opowiada spójną historię. Jeśli tak, masz solidny fundament. Jeśli znaczenie zależy od wizualnego rozmieszczenia, masz pracę do wykonania — a praca ta zwykle zaczyna się od tabel układu.

Tabele prezentacyjne i role=“presentation”

Układ e-maila buduje się za pomocą tabel. To nie jest wybór stylistyczny; to wymóg przetrwania, ponieważ układ oparty na tabelach to jedyne podejście, które renderuje się spójnie w całej macierzy klientów. Problem polega na tym, że tabele niosą znaczenie semantyczne. Domyślnie czytnik ekranu ogłasza <table> jako tabelę danych, odczytuje liczbę wierszy i kolumn oraz próbuje powiązać komórki z nagłówkami. Dla tabeli, która istnieje wyłącznie po to, by umieścić logo obok nagłówka, takie ogłoszenie to szum — a w obrębie zagnieżdżonego, wielotabelowego e-maila staje się męczącym, dezorientującym doświadczeniem.

Rozwiązaniem jest powiadomienie technologii wspomagającej, że te tabele to rusztowanie układu, a nie dane. Dodaj role="presentation" do każdej tabeli używanej do układu: <table role="presentation">. Usuwa to semantykę tabeli, dzięki czemu czytniki ekranu pomijają ogłoszenia wierszy/kolumn i po prostu odczytują zawartość w środku po kolei. To jedna z najważniejszych i najczęściej pomijanych technik w dostępności e-maili i musi być zastosowana do każdej tabeli układu, w tym zagnieżdżonych, a nie tylko do najbardziej zewnętrznego opakowania.

Kilka powiązanych praktyk to wzmacnia. Nie dodawaj summary, komórek nagłówkowych <th>, scope ani <caption> do tabel prezentacyjnych — to znacznik niosący znaczenie, zarezerwowany dla prawdziwych tabel danych. Jeśli Twój e-mail zawiera prawdziwe dane tabelaryczne, takie jak szczegółowy paragon, zrób odwrotnie: pozostaw je jako tabelę danych z właściwymi nagłówkami <th> i atrybutami scope, aby relacje były przekazywane. Zasadą jest spójność między wyglądem a semantyką. Zrobienie tego poprawnie w bibliotece szablonów jest żmudne i łatwo o regres, dlatego stanowi to kluczową część naszej pracy nad remediacją e-maili.

Obrazy i tekst alternatywny

Obrazy niosą w e-mailu dużą wagę, a wielu odbiorców widzi je z domyślnie wyłączonymi obrazami — niektórzy klienci blokują zdalne obrazy, dopóki użytkownik się nie zgodzi. To sprawia, że tekst alternatywny jest podwójnie ważny: jest zarówno wymogiem dostępności, jak i awaryjnym rozwiązaniem, które utrzymuje zrozumiałość Twojej wiadomości, gdy obrazy się nie ładują.

Każdy element <img> potrzebuje atrybutu alt. To, co się w nim znajdzie, zależy od celu obrazu. Dla obrazu informacyjnego — zdjęcia produktu, infografiki, wykresu — tekst alternatywny powinien przekazywać tę samą informację, którą daje obraz. „Niebieski but do biegania, widok z boku” jest bardziej użyteczny niż „image1.png”, a tekst alternatywny wykresu powinien podsumowywać wniosek, a nie tylko etykietować go jako wykres. W przypadku tekstu wyrenderowanego jako obraz, co wciąż zdarza się w nagłówkach promocyjnych, tekst alternatywny musi wiernie odtwarzać słowa, ponieważ w przeciwnym razie ta treść jest niewidoczna dla czytników ekranu i dla każdego z wyłączonymi obrazami.

Dla obrazów dekoracyjnych — elementów odstępu, tła ozdobnego, linii oddzielających, które nic nie wnoszą do znaczenia — użyj pustego atrybutu alt, zapisanego jako alt="". Mówi to wprost czytnikom ekranu, by pominęły obraz, zamiast ogłaszać nazwę pliku. Całkowite pominięcie atrybutu to nie to samo; brakujący alt często powoduje, że czytniki ekranu odczytują adres URL obrazu, co jest najgorszym z obu światów. Zachowaj szczególną ostrożność przy częstym wzorcu używania obrazu jako przycisku lub linku: tekst alternatywny tego obrazu musi opisywać działanie, takie jak „Sfinalizuj zakup”, a nie obrazek.

Jeszcze jeden punkt specyficzny dla e-maili: nigdy nie umieszczaj istotnych informacji wyłącznie w obrazie. Kod kuponu, numer potwierdzenia, link do rezygnacji z subskrypcji, główne wezwanie do działania — jeśli którekolwiek z nich istnieje wyłącznie jako piksele, znika dla użytkowników z wyłączonymi obrazami i czytników ekranu. Zachowaj krytyczną treść jako żywy, możliwy do zaznaczenia tekst.

Kontrast i tryb ciemny

Tekst musi być czytelny, co oznacza, że musi spełniać wymagania kontrastu. WCAG 2.2 wymaga współczynnika kontrastu co najmniej 4,5:1 dla normalnego tekstu i 3:1 dla dużego tekstu względem tła. Jasnoszary tekst na białym tle — wieloletni faworyt minimalistycznego projektowania e-maili — często zawodzi, podobnie jak blade przyciski i kolory linków o niskim kontraście. Te progi mają zastosowanie do e-maili tak samo jak do webu, a te same kryteria sukcesu WCAG 2.2 stanowią punkt odniesienia; nasz szerszy przegląd zgodności z WCAG wyjaśnia, jak te kryteria do siebie pasują.

E-mail dodaje komplikację, której web przeważnie nie ma: tryb ciemny. Wielu klientów — wśród nich Apple Mail, Outlook i Gmail — automatycznie przekształca e-maile, gdy użytkownik ma włączony tryb ciemny. Niektórzy po prostu zamieniają tło; inni agresywnie odwracają lub przebarwiają Twoją paletę, czasem częściowo. W rezultacie przycisk z ciemnym tekstem na jasnym kolorze marki może skończyć z ciemnym tekstem na ciemnym, odwróconym tle, redukując kontrast do zera. Czarny tekst wewnątrz kolorowego pola może stać się niewidoczny. Loga z przezroczystym tłem mogą zniknąć na ciemnym płótnie.

Nie ma uniwersalnej kontroli nad trybem ciemnym, a istniejące techniki różnią się w zależności od klienta, ale zasady defensywne są stabilne. Projektuj z myślą o obu trybach. Unikaj czystej czerni lub czystej bieli jako kolorów bazowych, ponieważ nie zostawiają one klientowi miejsca na dostosowanie. Nadaj logom i kluczowej grafice kontrastowy kontur lub solidną płytę tła, aby przetrwały inwersję. Testuj faktycznie wyrenderowany rezultat w trybie ciemnym w każdym głównym kliencie, zamiast ufać, że Twój projekt w trybie jasnym się przełoży. Celem jest, aby tekst i elementy interaktywne pozostawały powyżej progu kontrastu, niezależnie od tego, jak klient je odwróci.

Opisowe linki i dostępne przyciski

Użytkownicy czytników ekranu często przywołują listę wszystkich linków w wiadomości, by nawigować lub zdecydować, dokąd przejść. Na tej liście tekst linku pojawia się pozbawiony otaczającego kontekstu. Wiadomość pełna „Kliknij tutaj”, „Czytaj więcej” i „Dowiedz się więcej” tworzy bezużyteczny spis identycznych, pozbawionych znaczenia pozycji. Tekst każdego linku powinien mieć sens sam w sobie: „Przeczytaj nasz wiosenny raport o zrównoważonym rozwoju” lub „Śledź swoje zamówienie” mówi użytkownikowi dokładnie, dokąd prowadzi link, bez żadnego otaczającego zdania.

To samo dotyczy przycisków, które w e-mailu są zwykle linkami ostylowanymi tak, by wyglądały jak przyciski — często zbudowanymi techniką „kuloodpornego przycisku” z użyciem zagnieżdżonych tabel i kolorów tła, aby renderowały się w różnych klientach. Niezależnie od konstrukcji, dostępna nazwa przycisku musi opisywać jego działanie. Pusty lub niejasny przycisk, albo taki, którego tekst żyje wyłącznie w obrazie tła, to ślepy zaułek dla technologii wspomagającej. Jeśli przycisk jest oparty na obrazie, działanie należy do tekstu alternatywnego obrazu.

Spraw, by cele linków i przycisków były na tyle duże, by dało się je wygodnie dotknąć — WCAG 2.2 wprowadziło minimalny rozmiar celu, a na urządzeniu mobilnym zbyt mały cel dotknięcia frustruje wszystkich, nie tylko użytkowników z niepełnosprawnościami ruchowymi. Zadbaj, by linki były rozróżnialne czymś więcej niż tylko kolorem, ponieważ linki oparte wyłącznie na kolorze zawodzą u użytkowników z niedowidzeniem lub daltonizmem; podkreślenie to najbezpieczniejsza wskazówka. I nadaj każdemu linkowi prawdziwy, działający cel zamiast symbolu zastępczego. Niejasny tekst linku to jedno z najczęstszych uchybień, jakie widzimy, i pojawia się także w webie, nie tylko w e-mailu — nasze zestawienie częstych problemów z dostępnością, których należy unikać omawia ten sam wzorzec w szerszym kontekście.

Preheader i doświadczenie podglądu

Preheader — czasem nazywany tekstem podglądu — to fragment tekstu, który pojawia się obok lub pod wierszem tematu w skrzynce odbiorczej, zanim wiadomość zostanie otwarta. Wiele e-maili go marnuje, pozostawiając go domyślnie temu, co akurat przypadkiem wypadnie pierwsze: linijce „E-mail nie wyświetla się poprawnie?”, linkowi „wypisz się” lub ciągowi pustego tekstu alternatywnego. Dla użytkowników czytników ekranu nawigujących po swojej skrzynce odbiorczej, i dla każdego decydującego, czy otworzyć, ten zmarnowany preheader to stracona szansa na komunikację.

Napisz przemyślany, sensowny preheader podsumowujący cel e-maila i umieść go jako pierwszą treść tekstową w treści wiadomości, aby to on był tym, co podchwytuje skrzynka odbiorcza. Standardowa technika to ukryty blok tekstu blisko górnej części e-maila, ostylowany tak, by był wizualnie ukryty, ale wciąż dostępny dla klientów i technologii wspomagającej. Uważaj, jak go ukrywasz: źle ukryty preheader może albo pojawić się jako niepożądana widoczna linijka, albo zostać całkowicie pominięty przez czytniki ekranu. Wypełnij go odpowiednio, aby kolejna treść skrzynki odbiorczej nie przeciekała sąsiednim tekstem do podglądu.

Traktuj preheader jako część architektury informacji wiadomości. W połączeniu z jasnym wierszem tematu i mocnym nagłówkiem otwierającym daje każdemu odbiorcy — widzącemu lub nie — szybkie, trafne wyczucie tego, czym jest e-mail i dlaczego ma znaczenie.

Układ responsywny i powiększenie

E-maile są czytane na telefonach tak samo jak na komputerach stacjonarnych, a czytają je osoby, które powiększają, by powiększyć tekst. Oba przypadki wymagają, by układ się dostosowywał. Stały, szeroki układ, który wymusza przewijanie w poziomie na małym ekranie lub który się rozpada, gdy użytkownik zwiększy rozmiar tekstu, jest barierą — a WCAG 2.2 ma kryteria zarówno dla zawijania, jak i dla odstępów w tekście, które mają tu zastosowanie.

Buduj e-maile tak, by były responsywne: układ jednokolumnowy na wąskich ekranach jest niemal zawsze najbardziej solidnym i dostępnym wyborem, ponieważ zachowuje kolejność odczytu i unika treści ułożonych obok siebie, która rozpada się w nieprzewidywalny sposób. Tam, gdzie używasz zapytań medialnych do przełączania układów, pamiętaj, że niektórzy klienci je ignorują, więc domyślne renderowanie musi nadal być użyteczne. Ustaw rozmiary czcionek na tyle duże, by dało się je czytać bez powiększania — tekst główny poniżej około 14 do 16 pikseli jest trudny dla wielu osób na urządzeniach mobilnych — i unikaj ustalania wysokości wiersza lub odstępów między literami tak ciasno, że powiększony tekst nachodzi na siebie lub jest przycinany.

Testuj, co się dzieje, gdy użytkownik powiększa lub zwiększa systemowy rozmiar czcionki swojego urządzenia. Treść powinna się zawijać i pozostawać czytelna, zamiast wylewać się ze swojego kontenera lub znikać za innymi elementami. Nagrodą jest e-mail, który działa nie tylko dla użytkowników z niedowidzeniem, ale dla każdego czytającego na małym ekranie w niedoskonałych warunkach.

Testowanie w klientach i czytnikach ekranu

Nie możesz zweryfikować dostępności e-maila samą tylko inspekcją kodu, ponieważ całe wyzwanie polega na tym, że klienci renderują ten sam kod inaczej. Testowanie musi odbywać się w reprezentatywnej macierzy klientów i technologii wspomagających, w warunkach, których używają prawdziwi odbiorcy.

Pokryj co najmniej głównych klientów: Outlook (desktop w systemie Windows, plus wersje webowe i nowe), Gmail (web i aplikacja mobilna) oraz Apple Mail (macOS i iOS). Dla każdego sprawdź renderowanie zarówno w trybie jasnym, jak i ciemnym, z włączonymi i wyłączonymi obrazami oraz przy zwiększonym powiększeniu. Następnie nałóż na to czytniki ekranu — VoiceOver z Apple Mail w macOS i iOS, NVDA lub JAWS z Outlook i Gmail w systemie Windows oraz TalkBack z aplikacją Gmail w systemie Android. Wysłuchaj e-maila tak, jak zrobiłby to użytkownik czytnika ekranu: czy nagłówki są ogłaszane, czy kolejność odczytu jest logiczna, czy tabele układu milczą, czy linki mają sens na liście linków, czy obrazy ogłaszają użyteczny tekst alternatywny lub pozostają ciche, gdy są dekoracyjne?

Kontrole automatyczne mają swoje miejsce — potrafią szybko oznaczyć brakujące atrybuty alt, niski kontrast i brakujące atrybuty języka w wielu szablonach — ale nie potrafią ocenić, czy tekst alternatywny jest sensowny, czy kolejność odczytu opowiada właściwą historię, ani czy nazwa przycisku opisuje jego działanie. Ten osąd wymaga testowania ręcznego, najlepiej z udziałem osób, które na co dzień korzystają z technologii wspomagającej. Nasz przewodnik po ręcznych audytach dostępności wyjaśnia, dlaczego testowanie ludzkie jest niezastąpione, a nasze audyty przeprowadzane przez osoby z niepełnosprawnościami wnoszą do e-maili dokładnie tę perspektywę przeżytego doświadczenia.

Słowo ostrzeżenia: nie daj się skusić widżetom „nakładkowym” dla dostępności, które obiecują natychmiastową zgodność. Nie działają one w przypadku stron internetowych i są nieistotne dla e-maili, gdzie nie ma strony, w którą można by wstrzyknąć skrypt. Prawdziwa dostępność e-maili bierze się z naprawy znacznika, a nie z doczepianego dodatku.

Remediacja szablonów na poziomie ESP

Naprawa jednego e-maila jest pożyteczna. Naprawa źródła, które generuje każdy e-mail, jest transformacyjna. Większość organizacji wysyła za pośrednictwem dostawcy usług e-mail — Mailchimp, Klaviyo, Salesforce Marketing Cloud, Braze i podobnych — gdzie kampanie są składane z szablonów głównych, modułów wielokrotnego użytku i bloków treści typu „przeciągnij i upuść”. Jeśli te bazowe szablony niosą poprawki dostępności, każda przyszła wysyłka dziedziczy je automatycznie, a zespół marketingu nie musi pamiętać listy kontrolnej dla każdej kampanii.

To najbardziej opłacalne miejsce do inwestowania. Zremediuj szablon główny tak, by tabele układu niosły role="presentation", atrybut języka był ustawiony, struktura preheadera była na miejscu, a rusztowanie nagłówków było poprawne. Zremediuj każdy moduł wielokrotnego użytku — blok hero, kartę artykułu, przycisk, stopkę — tak, by cokolwiek zespół przeciągnie, było dostępne z założenia. Ustanów wzorce dla tekstu alternatywnego, aby redaktorzy byli zachęcani do jego napisania, i wpisz na stałe bezpieczne pod względem kontrastu, świadome trybu ciemnego kolory do palety marki używanej przez szablony.

Haczyk polega na tym, że kreatory typu „przeciągnij i upuść” mogą również cofać dostępność: kreator może usunąć role="presentation", zniekształcić znacznik przy eksporcie lub pozwolić redaktorowi wkleić niedostępny blok. Dlatego remediacja szablonów musi być połączona z zarządzaniem — wytycznymi, etapami przeglądu i okresowym ponownym testowaniem w miarę zmian ESP i jego zachowania przy eksporcie. Tu właśnie opłaca się wbudowanie dostępności w przepływ pracy; nasza usługa usprawniania procesów dostępności pomaga zespołom uczynić dostępne e-maile domyślnymi, a nie refleksją po fakcie, a doradztwo w zakresie dostępności dostosowuje je do Twojego szerszego programu zgodności. Dla organizacji objętych Europejskim Aktem o Dostępności dostępna komunikacja z klientami jest częścią obrazu, co przedstawia nasz przegląd zgodności z EAA.

QualiBooth łączy oprogramowanie do skanowania dostępności dla problemów, które maszyny wychwytują niezawodnie, z ekspercką remediacją ręczną dla decyzji wymagających osądu, których one podjąć nie mogą — w przypadku stron internetowych, dokumentów i e-maili na równi. Jeśli Twoje e-maile są częścią tego, jak obsługujesz klientów, zasługują na taką samą staranność jak reszta Twojego cyfrowego majątku.

Podsumowanie

Dostępność e-maili to nie pomniejszona wersja dostępności webowej — to pokrewna, ale odrębna dyscyplina, ukształtowana przez rozdrobniony krajobraz klientów, układy oparte na tabelach i silniki renderujące, które ignorują większość nowoczesnego webu. Dobra wiadomość jest taka, że techniki są dobrze ugruntowane: struktura semantyczna i solidny konspekt nagłówków, role="presentation" na każdej tabeli układu, sensowny tekst alternatywny z pustym alt dla dekoracji, kontrast przetrwujący tryb ciemny, linki i przyciski, które opisują same siebie, przemyślany preheader, układy responsywne wytrzymujące powiększenie oraz zdyscyplinowane testowanie w klientach i czytnikach ekranu. Zastosuj je na poziomie szablonu, a dostępność przestaje być zadaniem dla każdej kampanii i staje się właściwością Twojego systemu.

Korzyść jest realna. Dostępne e-maile docierają do większej liczby osób, czytają się przejrzyście z wyłączonymi obrazami i zwykle radzą sobie lepiej, ponieważ przejrzystość i solidność pomagają wszystkim. Jeśli chcesz pomocy, nasza usługa remediacji e-maili może przeprowadzić audyt Twoich szablonów, naprawić je na poziomie ESP i zweryfikować rezultat w całej macierzy klientów — a Ty możesz poprosić o demo lub uruchomić bezpłatne skanowanie swojej strony, by zobaczyć, jak wygląda reszta Twojego cyfrowego majątku.

Najczęściej zadawane pytania

Czy naprawdę potrzebuję role="presentation" na każdej tabeli układu? Tak. Bez tego czytniki ekranu ogłaszają każdą tabelę układu jako tabelę danych, odczytując liczbę wierszy i kolumn oraz zakłócając przepływ. Ponieważ układy e-maili zagnieżdżają tabele, atrybut musi być na każdej tabeli układu, nie tylko na zewnętrznym opakowaniu. Prawdziwe tabele danych, takie jak paragony, zachowują natomiast swoją semantykę danych.

Co powinienem umieścić w tekście alternatywnym obrazu dekoracyjnego? Użyj pustego atrybutu alt, zapisanego alt="", aby czytniki ekranu pominęły obraz. Nie pomijaj atrybutu całkowicie, ponieważ brakujący alt często powoduje odczytanie na głos nazwy pliku lub adresu URL obrazu.

Jak powstrzymać tryb ciemny przed zepsuciem mojego e-maila? Nie możesz w pełni kontrolować tego, jak każdy klient obsługuje tryb ciemny, ale możesz projektować defensywnie: unikaj czystej czerni i bieli, nadaj logom kontrastowe tło lub kontur, utrzymuj kontrast powyżej progów WCAG 2.2 i testuj wyrenderowany rezultat w trybie ciemnym w każdym głównym kliencie, zamiast zakładać, że Twój projekt w trybie jasnym się przeniesie.

Czy narzędzie automatyczne może uczynić mój e-mail dostępnym? Narzędzia automatyczne wychwytują niektóre problemy — brakujące atrybuty alt, niski kontrast, brakujące ustawienia języka — ale nie potrafią ocenić, czy tekst alternatywny jest sensowny, czy kolejność odczytu ma sens, ani czy linki i przyciski opisują swój cel. To wymaga ręcznego testowania z czytnikami ekranu. Widżety nakładkowe dla dostępności nie są rozwiązaniem i nie mają zastosowania do e-maili.

Czy lepiej naprawiać pojedyncze e-maile, czy szablony? Szablony. Remediacja szablonów głównych i modułów wielokrotnego użytku w Twoim ESP oznacza, że każda przyszła wysyłka dziedziczy poprawki, co jest znacznie bardziej opłacalne niż naprawianie kampanii pojedynczo. Połącz to z zarządzaniem, aby kreatory typu „przeciągnij i upuść” nie wprowadzały problemów ponownie.