Průvodce přístupností e-mailů pro HTML e-maily

Pro většinu organizací je e-mail nejčastějším kontaktním bodem se zákazníky. Potvrzení objednávky, obnovení hesla, měsíční výpis, newsletter — tyto zprávy často dorazí dlouho předtím, než někdo navštíví váš web, a dorazí mnohem častěji. Přesto je přístupnost e-mailů jedním z nejvíce přehlížených koutů digitální inkluze. Týmy, které intenzivně investují do přístupného webu, běžně odesílají kampaně postavené na zamotaném kódu, obsahu tvořeném pouze obrázky a tlačítkách, která čtečka obrazovky přečte jako „klikněte zde”.

Důvod je částečně historický a částečně technický: HTML e-mail je samostatná disciplína s vlastními omezeními, vlastními vykreslovacími jádry a vlastními způsoby selhání. Techniky, které jsou na moderním webu samozřejmostí — sémantické orientační body, rozvržení flexbox, vlastní vlastnosti CSS — jsou napříč spektrem e-mailových klientů nespolehlivé nebo zcela nefunkční. Učinit e-mail přístupným není stejná práce jako učinit přístupnou webovou stránku, a zacházení s nimi jako se shodnými je přesně tím důvodem, proč tolik e-mailů selhává.

Tento průvodce prochází, co přístupnost e-mailů ve skutečnosti vyžaduje: jak strukturovat kód tak, aby jej asistivní technologie mohly analyzovat, jak zacházet s prezentačními tabulkami, které stále tvoří základ rozvržení e-mailu, jak psát alt texty a odkazy, které dávají smysl mimo kontext, jak přežít tmavý režim a přiblížení a jak otestovat výsledek napříč Outlookem, Gmailem, Apple Mailem a čtečkami obrazovky. Pokud byste raději nechali odborníky, aby to udělali pro vaše šablony, naše služba nápravy e-mailů pokrývá celý zásobník.

Proč je HTML e-mail samostatná disciplína

Webová stránka se vykresluje v prohlížeči. Existuje hrstka mainstreamových prohlížečů, aktualizují se v předvídatelných intervalech a sbíhají se k webovým standardům. E-mail je opačný. Vaše zpráva může být otevřena v desítkách klientů — Outlook na Windows, Outlook na webu, nový Outlook, Gmail v prohlížeči, aplikace Gmail, Apple Mail na macOS a iOS, Yahoo, Samsung Email a mnoho dalších — z nichž každý má jiné vykreslovací jádro a jinou, často se zmenšující, podmnožinu podporovaného HTML a CSS.

Nejznámějším příkladem je desktopový Outlook na Windows, který historicky vykresloval e-mail pomocí jádra Microsoft Wordu místo skutečného jádra prohlížeče. Už jen to nutí e-mailové vývojáře zpět k tabulkovým rozvržením, vloženým stylům a defenzivním vzorům, které web před lety opustil. Mnoho klientů také odstraňuje bloky <style>, odmítá moderní CSS a přepisuje atributy, které považuje za nebezpečné.

Pro přístupnost na tom nesmírně záleží. Sémantické HTML, na které se spoléháte u webu — <nav>, <main>, orientační body ARIA — je v e-mailu často odstraněno nebo ignorováno. Nemůžete se spoléhat na jediný vykreslovací cíl. Přístupnost e-mailů je proto o vytváření zpráv, které se degradují elegantně: které zůstávají čitelné, navigovatelné a smysluplné, i když se rozvržení zhroutí, obrázky se nenačtou nebo se styly zahodí. Toto defenzivní myšlení je základem, na kterém staví vše ostatní v tomto průvodci, a proto e-mail patří do vyhrazeného programu služeb přístupnosti namísto toho, aby byl složen do obecné webové práce.

Sémantická struktura a logické pořadí čtení

I se všemi omezeními je nejcennější věcí, kterou můžete pro uživatele čtečky obrazovky udělat, dát e-mailu jasnou, lineární strukturu. Čtečky obrazovky čtou obsah v pořadí DOM, takže pořadí vašeho kódu je pořadím, ve kterém je vaše zpráva slyšet. Pokud váš design umístí propagační banner před skutečnou zprávu, banner je oznámen jako první — bez ohledu na to, jak rozvržení vypadá.

Pro vytvoření hierarchie použijte skutečné nadpisové prvky. E-mail by měl mít jeden logický nadpis nejvyšší úrovně (obvykle hlavní téma nebo nabídku) jako <h1>, přičemž následující sekce jsou označeny jako <h2> a <h3>. Uživatelé čtečky obrazovky procházejí podle nadpisů, aby zprávu prohlédli, takže dobře strukturovaná osnova promění stěnu textu v něco prohledatelného. Nefalšujte nadpisy velkým, tučným textem <span>; vizuálně to může vypadat jako nadpis, ale asistivní technologie slyší běžný text. Stejně tak používejte skutečné značení seznamů (<ul>, <ol>, <li>) pro seznamy a nastavte jazyk dokumentu atributem lang na prvku <html>, aby čtečky obrazovky používaly správnou výslovnost a hlas.

Pořadí čtení musí také dávat smysl samo o sobě. Přečtěte si svůj kód shora dolů, ignorujte veškeré stylování, a zeptejte se, zda stále vypráví soudržný příběh. Pokud ano, máte pevný základ. Pokud význam závisí na vizuálním uspořádání, máte před sebou práci — a tato práce obvykle začíná u tabulek rozvržení.

Prezentační tabulky a role=“presentation”

Rozvržení e-mailu je postaveno na tabulkách. Není to stylistická volba; je to požadavek na přežití, protože tabulkové rozvržení je jediný přístup, který se vykresluje konzistentně napříč spektrem klientů. Problém je, že tabulky nesou sémantický význam. Ve výchozím nastavení čtečka obrazovky oznámí <table> jako datovou tabulku, přečte počet řádků a sloupců a pokusí se přiřadit buňky k záhlavím. U tabulky, která existuje čistě pro umístění loga vedle nadpisu, je toto oznámení šumem — a napříč vnořeným e-mailem s více tabulkami se stává vyčerpávajícím, dezorientujícím zážitkem.

Náprava spočívá v tom, že asistivní technologii sdělíte, že tyto tabulky jsou lešením rozvržení, nikoli daty. Přidejte role="presentation" ke každé tabulce použité pro rozvržení: <table role="presentation">. To odstraní sémantiku tabulky, takže čtečky obrazovky přeskočí oznámení o řádcích/sloupcích a jednoduše přečtou obsah uvnitř v pořadí. Je to jedna z nejdůležitějších a nejčastěji opomíjených technik v přístupnosti e-mailů a musí být aplikována na každou tabulku rozvržení, včetně vnořených, nejen na nejvnějšnější obal.

Několik souvisejících postupů to posiluje. Nepřidávejte summary, buňky záhlaví <th>, scope ani <caption> k prezentačním tabulkám — to je značení nesoucí význam vyhrazené pro skutečné datové tabulky. Pokud váš e-mail obsahuje skutečná tabulková data, jako je položkový účet, udělejte opak: ponechte je jako datovou tabulku se správnými záhlavími <th> a atributy scope, aby byly vztahy zprostředkovány. Principem je konzistence mezi vzhledem a sémantikou. Dostat to správně napříč knihovnou šablon je úmorné a snadno se to vrací zpět, a proto je to základní součástí naší práce na nápravě e-mailů.

Obrázky a alt texty

Obrázky nesou v e-mailu velkou váhu a mnoho příjemců je vidí ve výchozím nastavení s vypnutými obrázky — někteří klienti blokují vzdálené obrázky, dokud se uživatel nepřihlásí. To činí alt text dvojnásobně důležitým: je to zároveň požadavek na přístupnost i záloha, která udržuje vaši zprávu srozumitelnou, když se obrázky nenačtou.

Každý prvek <img> potřebuje atribut alt. Co do něj patří, závisí na účelu obrázku. U informativního obrázku — fotografie produktu, infografika, graf — by měl alt text zprostředkovat stejnou informaci, jakou obrázek poskytuje. „Modrá běžecká bota, pohled z boku” je užitečnější než „image1.png” a alt text grafu by měl shrnout hlavní sdělení, ne jej jen označit jako graf. U textu vykresleného jako obrázek, což se u propagačních nadpisů stále děje, musí alt text reprodukovat slova přesně, protože jinak je tento obsah neviditelný pro čtečky obrazovky a pro každého s vypnutými obrázky.

U dekorativních obrázků — mezerníky, ozdoby pozadí, oddělovače, které k významu nic nepřidávají — použijte prázdný atribut alt, zapsaný jako alt="". To explicitně sděluje čtečkám obrazovky, aby obrázek přeskočily, místo aby oznamovaly název souboru. Vynechání atributu úplně není totéž; chybějící alt často způsobí, že čtečky obrazovky přečtou URL obrázku, což je nejhorší z obou světů. Buďte obzvláště opatrní u běžného vzoru používání obrázku jako tlačítka nebo odkazu: alt text tohoto obrázku musí popisovat akci, například „Dokončete svůj nákup”, nikoli obrázek.

Ještě jeden bod specifický pro e-mail: nikdy nedávejte zásadní informaci pouze do obrázku. Slevový kód, potvrzovací číslo, odkaz na odhlášení, hlavní výzva k akci — pokud kterákoli z nich existuje pouze jako pixely, mizí pro uživatele s vypnutými obrázky a uživatele čteček obrazovky. Udržujte kritický obsah jako živý, vybíratelný text.

Kontrast a tmavý režim

Text musí být čitelný, což znamená, že musí splňovat požadavky na kontrast. WCAG 2.2 požaduje kontrastní poměr alespoň 4,5:1 pro běžný text a 3:1 pro velký text vůči jeho pozadí. Světle šedý text na bílém pozadí — věčný oblíbenec minimalistického návrhu e-mailů — často selhává, stejně jako bledá tlačítka a barvy odkazů s nízkým kontrastem. Tyto prahové hodnoty platí pro e-mail stejně jako pro web a stejná kritéria úspěchu WCAG 2.2 jsou měřítkem; náš širší přehled souladu s WCAG vysvětluje, jak tato kritéria zapadají do sebe.

E-mail přidává komplikaci, kterou web většinou nemá: tmavý režim. Mnoho klientů — mezi nimi Apple Mail, Outlook, Gmail — automaticky transformuje e-maily, když má uživatel zapnutý tmavý režim. Některé jednoduše prohodí pozadí; jiné agresivně invertují nebo přebarvují vaši paletu, někdy částečně. Výsledkem je, že tlačítko s tmavým textem na světlé barvě značky může skončit s tmavým textem na tmavém invertovaném pozadí, čímž kontrast klesne na nulu. Černý text uvnitř barevného rámečku se může stát neviditelným. Loga s průhledným pozadím mohou zmizet na tmavém plátně.

Nad tmavým režimem neexistuje univerzální kontrola a techniky, které existují, se liší podle klienta, ale defenzivní principy jsou stálé. Navrhujte s oběma režimy na mysli. Vyhněte se čistě černé nebo čistě bílé jako základním barvám, protože nenechávají klientovi prostor pro úpravu. Dejte logům a klíčové grafice kontrastní obrys nebo plnou podkladovou desku, aby přežily inverzi. Otestujte skutečný vykreslený výsledek v tmavém režimu v každém hlavním klientovi, místo abyste důvěřovali, že se váš návrh ve světlém režimu přeloží. Cílem je, aby text a interaktivní prvky zůstaly nad prahem kontrastu bez ohledu na to, kterým směrem je klient převrátí.

Popisné odkazy a přístupná tlačítka

Uživatelé čteček obrazovky si často vyvolají seznam všech odkazů ve zprávě, aby navigovali nebo se rozhodli, kam jít. V tomto seznamu se text odkazu objevuje zbavený okolního kontextu. Zpráva plná „klikněte zde”, „číst více” a „zjistit více” vytváří neužitečný inventář identických, bezvýznamných položek. Text každého odkazu by měl dávat smysl sám o sobě: „Přečtěte si naši jarní zprávu o udržitelnosti” nebo „Sledujte svou objednávku” sděluje uživateli přesně, kam odkaz vede, bez jakékoli okolní věty.

Totéž platí pro tlačítka, která jsou v e-mailu obvykle odkazy stylizované tak, aby vypadaly jako tlačítka — často vytvořené technikou „neprůstřelného tlačítka” pomocí vnořených tabulek a barev pozadí, aby se vykreslila napříč klienty. Ať už je konstrukce jakákoli, přístupný název tlačítka musí popisovat jeho akci. Prázdné nebo vágní tlačítko, nebo takové, jehož text žije pouze v obrázku pozadí, je slepou uličkou pro asistivní technologii. Pokud je tlačítko založené na obrázku, akce patří do alt textu obrázku.

Učiňte cíle odkazů a tlačítek dostatečně velkými pro pohodlné klepnutí — WCAG 2.2 zavedl minimum velikosti cíle a na mobilu příliš malý cíl klepnutí frustruje každého, nejen uživatele s motorickým postižením. Zajistěte, aby odkazy byly rozlišitelné více než jen barvou, protože odkazy odlišené pouze barvou selhávají pro uživatele se slabým zrakem nebo barvoslepostí; podtržení je nejbezpečnější vodítko. A dejte každému odkazu skutečný, funkční cíl namísto zástupného symbolu. Vágní text odkazu je jedním z nejčastějších selhání, která vidíme, a objevuje se i na webu, nejen v e-mailu — náš přehled běžných problémů přístupnosti, kterým se vyhnout pokrývá stejný vzor v širším kontextu.

Preheader a zážitek z náhledu

Preheader — někdy nazývaný text náhledu — je úryvek textu, který se objeví vedle nebo pod předmětem ve schránce, předtím než je zpráva otevřena. Mnoho e-mailů jej promrhá a ponechá jej výchozímu textu, který náhodou přijde jako první: řádek „E-mail se nezobrazuje správně?”, odkaz „odhlásit se” nebo řetězec prázdného alt textu. Pro uživatele čteček obrazovky procházející svou schránkou a pro každého, kdo se rozhoduje, zda otevřít, je tento promarněný preheader zmeškanou šancí komunikovat.

Napište záměrný, smysluplný preheader, který shrnuje účel e-mailu, a umístěte jej jako první textový obsah v těle, aby to bylo to, co schránka zachytí. Standardní technikou je skrytý blok textu poblíž horní části e-mailu, stylizovaný tak, aby byl vizuálně skrytý, ale stále dostupný klientům a asistivní technologii. Buďte opatrní s tím, jak jej skryjete: špatně skrytý preheader se může buď zobrazit jako nežádoucí viditelný řádek, nebo jej čtečky obrazovky mohou úplně přeskočit. Doplňte jej vhodně, aby koncový obsah schránky neprosakoval sousední text do náhledu.

Zacházejte s preheaderem jako se součástí informační architektury zprávy. V kombinaci s jasným předmětem a silným úvodním nadpisem dává každému příjemci — vidoucímu i nevidoucímu — rychlý, přesný pocit toho, co e-mail je a proč na něm záleží.

Responzivní rozvržení a přiblížení

E-maily se čtou na telefonech stejně jako na stolních počítačích a čtou je lidé, kteří přibližují, aby zvětšili text. Obojí vyžaduje, aby se rozvržení přizpůsobilo. Pevné, široké rozvržení, které vynucuje horizontální posouvání na malé obrazovce nebo které se rozbije, když uživatel zvětší velikost textu, je překážkou — a WCAG 2.2 má kritéria jak pro přeskupení, tak pro mezery v textu, která zde platí.

Vytvářejte e-maily jako responzivní: jednosloupcové rozvržení na úzkých obrazovkách je téměř vždy nejrobustnější a nejpřístupnější volbou, protože zachovává pořadí čtení a vyhýbá se obsahu vedle sebe, který se nepředvídatelně hroutí. Když používáte mediální dotazy k přepínání rozvržení, pamatujte, že někteří klienti je ignorují, takže výchozí vykreslení musí být stále použitelné. Nastavte velikosti písma dostatečně velké pro čtení bez přibližování — text těla pod zhruba 14 až 16 pixely je pro mnoho lidí na mobilu obtížný — a vyhněte se fixování výšky řádku nebo mezer mezi písmeny tak těsně, že se zvětšený text překrývá nebo ořezává.

Otestujte, co se stane, když uživatel přiblíží nebo zvětší velikost systémového písma svého zařízení. Obsah by se měl přeskupit a zůstat čitelný, místo aby přetékal svůj kontejner nebo mizel za jinými prvky. Odměnou je e-mail, který funguje nejen pro uživatele se slabým zrakem, ale pro každého, kdo čte na malé obrazovce v nedokonalých podmínkách.

Testování napříč klienty a čtečkami obrazovky

Přístupnost e-mailu nemůžete ověřit pouze kontrolou kódu, protože celá výzva spočívá v tom, že klienti vykreslují stejný kód odlišně. Testování se musí odehrávat napříč reprezentativní maticí klientů a asistivních technologií, za podmínek, které skuteční příjemci používají.

Pokryjte minimálně hlavní klienty: Outlook (desktop na Windows, plus webové a nové verze), Gmail (web a mobilní aplikace) a Apple Mail (macOS a iOS). U každého zkontrolujte vykreslení ve světlém i tmavém režimu, se zapnutými a vypnutými obrázky a při zvětšeném přiblížení. Poté navrstvěte čtečky obrazovky — VoiceOver s Apple Mailem na macOS a iOS, NVDA nebo JAWS s Outlookem a Gmailem na Windows a TalkBack s aplikací Gmail na Androidu. Poslouchejte e-mail tak, jak by jej slyšel uživatel čtečky obrazovky: jsou nadpisy oznámeny, je pořadí čtení logické, jsou tabulky rozvržení tiché, dávají odkazy v seznamu odkazů smysl, oznamují obrázky užitečný alt text nebo zůstávají tiché, když jsou dekorativní?

Automatické kontroly mají své místo — mohou rychle označit chybějící atributy alt, nízký kontrast a chybějící jazykové atributy napříč mnoha šablonami — ale nemohou posoudit, zda je alt text smysluplný, zda pořadí čtení vypráví správný příběh nebo zda název tlačítka popisuje jeho akci. Tento úsudek vyžaduje manuální testování, ideálně včetně testování lidmi, kteří asistivní technologii používají každý den. Náš průvodce manuálními audity přístupnosti vysvětluje, proč je lidské testování nenahraditelné, a naše audity osobami se zdravotním postižením přinášejí přesně tuto perspektivu prožité zkušenosti do e-mailu.

Slovo varování: nenechte se zlákat „překryvnými” widgety přístupnosti, které slibují okamžitý soulad. Nefungují pro weby a jsou irelevantní pro e-mail, kde není žádná stránka, do které by se vložil skript. Skutečná přístupnost e-mailů pochází z opravy kódu, nikoli z přidaného doplňku.

Náprava šablon na úrovni ESP

Oprava jednoho e-mailu je užitečná. Oprava zdroje, který generuje každý e-mail, je transformativní. Většina organizací odesílá prostřednictvím poskytovatele e-mailových služeb — Mailchimp, Klaviyo, Salesforce Marketing Cloud, Braze a podobně — kde se kampaně sestavují z hlavních šablon, znovupoužitelných modulů a obsahových bloků typu táhni a pusť. Pokud tyto podkladové šablony nesou opravy přístupnosti, každé budoucí odeslání je automaticky zdědí a marketingový tým si nemusí pamatovat kontrolní seznam pro každou kampaň.

Toto je nejnákladově nejefektivnější místo pro investici. Napravte hlavní šablonu tak, aby tabulky rozvržení nesly role="presentation", byl nastaven jazykový atribut, byla na místě struktura preheaderu a lešení nadpisů bylo správné. Napravte každý znovupoužitelný modul — hero blok, kartu článku, tlačítko, patičku — aby cokoli, co tým přetáhne dovnitř, bylo přístupné konstrukcí. Stanovte vzory pro alt text, aby byli editoři vyzváni k jeho napsání, a zapečte barvy bezpečné pro kontrast a uvědomělé vůči tmavému režimu do palety značky, kterou šablony používají.

Háček je v tom, že nástroje táhni a pusť mohou také vrátit přístupnost zpět: nástroj může odstranit role="presentation", zmrzačit kód při exportu nebo nechat editora vložit nepřístupný blok. Náprava šablon proto musí být spárována se správou — pokyny, kroky revize a pravidelným opětovným testováním, jak se ESP a jeho chování při exportu mění. Právě tam se vyplatí zabudování přístupnosti do pracovního postupu; naše služba zlepšení procesu přístupnosti pomáhá týmům učinit přístupný e-mail výchozím stavem namísto dodatečné myšlenky a konzultace přístupnosti jej sladí s vaším širším programem souladu. Pro organizace spadající pod Evropský akt o přístupnosti jsou přístupné komunikace se zákazníky součástí obrazu, což vykládá náš přehled souladu s EAA.

QualiBooth kombinuje software pro skenování přístupnosti pro problémy, které stroje spolehlivě zachytí, s odbornou manuální nápravou pro rozhodnutí vyžadující úsudek, která nezvládnou — napříč weby, dokumenty i e-mailem. Pokud jsou vaše e-maily součástí toho, jak sloužíte zákazníkům, zaslouží si stejnou pečlivost jako zbytek vašeho digitálního majetku.

Závěr

Přístupnost e-mailů není menší verzí webové přístupnosti — je to příbuzná, ale odlišná disciplína, formovaná roztříštěnou krajinou klientů, tabulkovými rozvrženími a vykreslovacími jádry, která ignorují velkou část moderního webu. Dobrou zprávou je, že techniky jsou dobře zavedené: sémantická struktura a zdravá osnova nadpisů, role="presentation" na každé tabulce rozvržení, smysluplný alt text s prázdným alt pro dekoraci, kontrast, který přežije tmavý režim, odkazy a tlačítka, která se popisují, záměrný preheader, responzivní rozvržení, která vydrží přiblížení, a disciplinované testování napříč klienty a čtečkami obrazovky. Aplikujte je na úrovni šablon a přístupnost přestane být dřinou pro jednotlivé kampaně a stane se vlastností vašeho systému.

Odměna je skutečná. Přístupné e-maily zasáhnou více lidí, čtou se jasně s vypnutými obrázky a obvykle si vedou lépe, protože jasnost a robustnost pomáhají každému. Pokud chcete pomoc, naše služba nápravy e-mailů může provést audit vašich šablon, opravit je na úrovni ESP a ověřit výsledek napříč celou maticí klientů — a můžete si vyžádat demo nebo spustit bezplatné skenování svého webu, abyste viděli, kde stojí zbytek vašeho digitálního majetku.

Často kladené otázky

Opravdu potřebuji role="presentation" na každé tabulce rozvržení? Ano. Bez toho čtečky obrazovky oznámí každou tabulku rozvržení jako datovou tabulku, přečtou počty řádků a sloupců a naruší tok. Protože rozvržení e-mailů vnořují tabulky, musí být atribut na každé tabulce rozvržení, nejen na vnějším obalu. Skutečné datové tabulky, jako jsou účtenky, si místo toho zachovají svou datovou sémantiku.

Co mám dát do alt textu pro dekorativní obrázek? Použijte prázdný atribut alt, zapsaný alt="", aby čtečky obrazovky obrázek přeskočily. Nevynechávejte atribut úplně, protože chybějící alt často způsobí, že se název souboru nebo URL obrázku přečte nahlas.

Jak zabráním tomu, aby tmavý režim rozbil můj e-mail? Nemůžete plně kontrolovat, jak každý klient zachází s tmavým režimem, ale můžete navrhovat defenzivně: vyhněte se čisté černé a bílé, dejte logům kontrastní pozadí nebo obrys, udržujte kontrast nad prahy WCAG 2.2 a otestujte vykreslený výsledek v tmavém režimu v každém hlavním klientovi, místo abyste předpokládali, že se váš návrh ve světlém režimu přenese.

Může automatický nástroj učinit můj e-mail přístupným? Automatické nástroje zachytí některé problémy — chybějící atributy alt, nízký kontrast, chybějící jazyková nastavení — ale nemohou posoudit, zda je alt text smysluplný, zda pořadí čtení dává smysl nebo zda odkazy a tlačítka popisují svůj účel. To vyžaduje manuální testování se čtečkami obrazovky. Překryvné widgety přístupnosti nejsou řešením a nejsou použitelné pro e-mail.

Je lepší opravovat jednotlivé e-maily, nebo šablony? Šablony. Náprava hlavních šablon a znovupoužitelných modulů ve vašem ESP znamená, že každé budoucí odeslání zdědí opravy, což je mnohem nákladově efektivnější než opravovat kampaně po jedné. Spárujte to se správou, aby nástroje táhni a pusť znovu nezavedly problémy.