E-mail-akadálymentesítési útmutató HTML-levelekhez

A legtöbb szervezet számára az e-mail a leggyakoribb kapcsolódási pont az ügyfelekkel. Egy rendelés-visszaigazolás, egy jelszó-visszaállítás, egy havi kivonat, egy hírlevél — ezek az üzenetek gyakran sokkal azelőtt megérkeznek, hogy valaki ellátogatna a webhelyére, és sokkal gyakrabban érkeznek. Az e-mailek akadálymentesítése mégis a digitális befogadás egyik leginkább elhanyagolt sarka. Azok a csapatok, amelyek sokat fektetnek egy akadálymentes webhelybe, rendszeresen küldenek olyan kampányokat, amelyek kusza jelölőkódra, kizárólag képből álló tartalomra és olyan gombokra épülnek, amelyeket a képernyőolvasó „kattintson ide” formában olvas fel.

Az ok részben történelmi, részben technikai: a HTML e-mail önálló szakterület, saját korlátaival, saját megjelenítőmotorjaival és saját hibamódjaival. Azok a technikák, amelyek a modern weben magától értetődők — szemantikus tájékozódási pontok, flexbox elrendezések, CSS egyéni tulajdonságok — az e-mail-kliensek skáláján megbízhatatlanok vagy teljesen működésképtelenek. Egy e-mailt akadálymentessé tenni nem ugyanaz a feladat, mint egy weboldalt akadálymentessé tenni, és az, hogy azonosként kezeljük őket, pontosan ezért bukik el oly sok e-mail.

Ez az útmutató végigveszi, hogy mit igényel valójában az e-mailek akadálymentesítése: hogyan strukturáljuk a jelölőkódot úgy, hogy a segítő technológia értelmezni tudja, hogyan kezeljük a prezentációs táblázatokat, amelyek még mindig az e-mail elrendezésének alapját képezik, hogyan írjunk alt szöveget és linkeket, amelyeknek kontextuson kívül is van értelmük, hogyan éljük túl a sötét módot és a nagyítást, és hogyan teszteljük az eredményt Outlookban, Gmailben, Apple Mailben és képernyőolvasókkal. Ha inkább szakemberekkel végeztetné el ezt a sablonjaihoz, e-mail-helyreállítási szolgáltatásunk lefedi a teljes vertikumot.

Miért önálló szakterület a HTML e-mail

Egy weboldal a böngészőben jelenik meg. Maroknyi mainstream böngésző létezik, kiszámítható ütemezés szerint frissülnek, és a webes szabványok felé konvergálnak. Az e-mail ennek az ellenkezője. Az üzenete tucatnyi kliensben nyitható meg — Outlook Windowson, Outlook a weben, az új Outlook, Gmail böngészőben, a Gmail alkalmazás, Apple Mail macOS-en és iOS-en, Yahoo, Samsung Email és sok más — mindegyik más megjelenítőmotorral és más, gyakran zsugorodó, támogatott HTML- és CSS-részhalmazzal.

A leghírhedtebb példa a Windows asztali Outlookja, amely történelmileg a Microsoft Word motorjával jelenítette meg az e-mailt egy valódi böngészőmotor helyett. Ez önmagában visszakényszeríti az e-mail-fejlesztőket a táblázat-alapú elrendezésekhez, a beágyazott stílusokhoz és azokhoz a védekező mintákhoz, amelyeket a web évekkel ezelőtt elhagyott. Sok kliens emellett eltávolítja a <style> blokkokat, elutasítja a modern CSS-t, és átírja az általa veszélyesnek tartott attribútumokat.

Az akadálymentesítés szempontjából ez óriási jelentőséggel bír. A szemantikus HTML, amelyre egy webhelynél támaszkodik — <nav>, <main>, ARIA tájékozódási pontok — gyakran eltávolításra vagy figyelmen kívül hagyásra kerül az e-mailben. Nem támaszkodhat egyetlen megjelenítési célpontra. Az e-mailek akadálymentesítése ezért olyan üzenetek építéséről szól, amelyek elegánsan romlanak le: amelyek olvashatók, navigálhatók és értelmesek maradnak akkor is, ha az elrendezés összeomlik, a képek nem töltődnek be, vagy a stílusokat eldobják. Ez a védekező gondolkodásmód az az alap, amelyre az útmutatóban szereplő minden más épül, és ezért tartozik az e-mail egy dedikált akadálymentesítési szolgáltatások programba, ahelyett hogy az általános webes munkába olvasztanánk.

Szemantikus szerkezet és logikus olvasási sorrend

Minden korlát ellenére a legértékesebb dolog, amit egy képernyőolvasót használó felhasználóért tehet, az, hogy világos, lineáris szerkezetet ad az e-mailnek. A képernyőolvasók a tartalmat DOM-sorrendben olvassák, így a jelölőkód sorrendje az a sorrend, amelyben az üzenetét hallják. Ha a tervezése egy promóciós szalagcímet helyez a tényleges üzenet elé, a szalagcímet hirdetik be először — függetlenül attól, hogy az elrendezés hogyan néz ki.

Használjon valódi címsorelemeket a hierarchia létrehozásához. Egy e-mailnek legyen egy logikus, legfelső szintű címsora (jellemzően a fő téma vagy ajánlat) <h1>-ként, az ezt követő szakaszok pedig <h2> és <h3> jelöléssel. A képernyőolvasót használók címsorok szerint navigálnak, hogy átfussák az üzenetet, így egy jól strukturált vázlat egy szövegfalat valami átfuthatóvá alakít. Ne hamisítson címsorokat nagy, félkövér <span> szöveggel; vizuálisan címsornak tűnhet, de a segítő technológia hétköznapi törzsszövegként hallja. Ugyanígy használjon valódi listajelölést (<ul>, <ol>, <li>) a listákhoz, és állítsa be a dokumentum nyelvét a lang attribútummal a <html> elemen, hogy a képernyőolvasók a megfelelő kiejtést és hangot használják.

Az olvasási sorrendnek önmagában is értelmesnek kell lennie. Olvassa el a jelölőkódját fentről lefelé, minden stílust figyelmen kívül hagyva, és kérdezze meg, hogy még mindig koherens történetet mesél-e el. Ha igen, szilárd alapja van. Ha a jelentés a vizuális elrendezéstől függ, akkor van még munka — és ez a munka általában az elrendezési táblázatokkal kezdődik.

Prezentációs táblázatok és a role=“presentation”

Az e-mail elrendezése táblázatokkal épül fel. Ez nem stilisztikai választás; túlélési követelmény, mert a táblázat-alapú elrendezés az egyetlen megközelítés, amely következetesen jelenik meg a kliensek skáláján. A probléma az, hogy a táblázatok szemantikus jelentést hordoznak. Alapértelmezés szerint a képernyőolvasó adattáblázatként hirdeti be a <table> elemet, felolvassa a sorok és oszlopok számát, és megpróbálja a cellákat a fejlécekhez társítani. Egy olyan táblázat esetében, amely pusztán azért létezik, hogy egy logót egy címsor mellé helyezzen, ez a bejelentés zaj — és egy egymásba ágyazott, többtáblázatos e-mailben kimerítő, dezorientáló élménnyé válik.

A megoldás az, hogy közöljük a segítő technológiával, hogy ezek a táblázatok elrendezési állványzat, nem adat. Adjon hozzá role="presentation"-t minden elrendezéshez használt táblázathoz: <table role="presentation">. Ez eltávolítja a táblázat szemantikáját, így a képernyőolvasók kihagyják a sor-/oszlopbejelentéseket, és egyszerűen sorrendben felolvassák a benne lévő tartalmat. Ez az egyik legfontosabb és leggyakrabban kihagyott technika az e-mailek akadálymentesítésében, és minden elrendezési táblázatra alkalmazni kell, beleértve az egymásba ágyazottakat is, nemcsak a legkülső burkolóra.

Néhány kapcsolódó gyakorlat megerősíti ezt. Ne adjon summary-t, <th> fejléccellákat, scope-ot vagy <caption>-t a prezentációs táblázatokhoz — ezek a valódi adattáblázatok számára fenntartott, jelentéshordozó jelölések. Ha az e-mailje valódi táblázatos adatot tartalmaz, például egy tételes nyugtát, tegye az ellenkezőjét: hagyja adattáblázatként, megfelelő <th> fejlécekkel és scope attribútumokkal, hogy a kapcsolatok közvetítve legyenek. Az elv a megjelenés és a szemantika közötti következetesség. Ezt jól eltalálni egy sablonkönyvtárban aprólékos és könnyen visszacsúszik, ezért alapvető része az e-mail-helyreállítási munkánknak.

Képek és alt szövegek

A képek nagy súlyt hordoznak az e-mailben, és sok címzett alapértelmezés szerint kikapcsolt képekkel látja őket — egyes kliensek blokkolják a távoli képeket, amíg a felhasználó nem engedélyezi azokat. Ez kétszeresen fontossá teszi az alt szöveget: egyszerre akadálymentesítési követelmény és az a tartalék, amely érthetően tartja az üzenetét, amikor a képek nem töltődnek be.

Minden <img> elemnek szüksége van egy alt attribútumra. Hogy mi kerül bele, az a kép céljától függ. Egy informatív kép esetében — terméfotó, infografika, diagram — az alt szövegnek ugyanazt az információt kell közvetítenie, amelyet a kép nyújt. A „Kék futócipő, oldalnézet” hasznosabb, mint az „image1.png”, és egy diagram alt szövegének össze kell foglalnia a lényeget, nem csak diagramként megcímkéznie. A képként megjelenített szöveg esetében, ami a promóciós címsoroknál még mindig előfordul, az alt szövegnek pontosan reprodukálnia kell a szavakat, mert egyébként az a tartalom láthatatlan a képernyőolvasók és mindenki számára, akinél ki vannak kapcsolva a képek.

A dekoratív képek esetében — térközök, háttérdíszek, elválasztók, amelyek semmit sem adnak a jelentéshez — használjon üres alt attribútumot, alt="" formában írva. Ez kifejezetten közli a képernyőolvasókkal, hogy hagyják ki a képet, ahelyett hogy bejelentenének egy fájlnevet. Az attribútum teljes elhagyása nem ugyanaz; egy hiányzó alt gyakran azt eredményezi, hogy a képernyőolvasók felolvassák a kép URL-jét, ami mindkét világ legrosszabbja. Legyen különösen óvatos azzal a gyakori mintával, amikor egy képet gombként vagy linkként használnak: annak a képnek az alt szövegének a műveletet kell leírnia, például „Fejezze be a vásárlást”, nem a képet.

Még egy e-mail-specifikus pont: soha ne tegyen lényeges információt kizárólag egy képbe. Egy kuponkód, egy visszaigazolási szám, egy leiratkozási link, a fő cselekvésre ösztönzés — ha ezek bármelyike csak pixelekként létezik, eltűnnek a kikapcsolt képes és a képernyőolvasót használó felhasználók számára. Tartsa a kritikus tartalmat élő, kijelölhető szövegként.

Kontraszt és sötét mód

A szövegnek olvashatónak kell lennie, ami azt jelenti, hogy meg kell felelnie a kontrasztkövetelményeknek. A WCAG 2.2 legalább 4,5:1 kontrasztarányt kér a normál szöveghez és 3:1-et a nagy szöveghez a háttérhez képest. A világosszürke szöveg fehér háttéren — a minimalista e-mail-tervezés örök kedvence — gyakran megbukik, ugyanígy a halvány gombok és az alacsony kontrasztú linkszínek is. Ezek a küszöbértékek ugyanúgy vonatkoznak az e-mailre, mint a webre, és ugyanazok a WCAG 2.2 sikerkritériumok a mérce; szélesebb körű WCAG-megfelelőségi áttekintésünk elmagyarázza, hogyan illeszkednek össze ezek a kritériumok.

Az e-mail hozzáad egy bonyodalmat, amely a webnél többnyire nincs jelen: a sötét módot. Sok kliens — köztük az Apple Mail, az Outlook, a Gmail — automatikusan átalakítja az e-maileket, amikor a felhasználónál be van kapcsolva a sötét mód. Egyesek egyszerűen felcserélik a hátteret; mások agresszíven invertálják vagy átszínezik a palettáját, néha részlegesen. Az eredmény az, hogy egy sötét szöveget világos márkaszínen tartalmazó gomb végül sötét szöveggel egy sötét, invertált háttéren köthet ki, nullára csökkentve a kontrasztot. Egy színes dobozon belüli fekete szöveg láthatatlanná válhat. Az átlátszó hátterű logók eltűnhetnek egy sötét vásznon.

Nincs univerzális kontroll a sötét mód felett, és a létező technikák kliensenként eltérnek, de a védekező elvek állandóak. Tervezzen mindkét módot szem előtt tartva. Kerülje a tiszta feketét vagy a tiszta fehéret alapszínként, mert ezek nem hagynak teret a kliensnek a kiigazításra. Adjon a logóknak és a kulcsfontosságú grafikáknak kontrasztos körvonalat vagy tömör háttérlapot, hogy túléljék az invertálást. Tesztelje a tényleges megjelenített eredményt sötét módban minden főbb kliensben, ahelyett hogy bízna abban, hogy a világos módú tervezése lefordítódik. A cél az, hogy a szöveg és az interaktív elemek a kontrasztküszöb felett maradjanak, függetlenül attól, hogy a kliens melyik irányba fordítja őket.

Leíró linkek és akadálymentes gombok

A képernyőolvasót használók gyakran előhívják az üzenet összes linkjének listáját, hogy navigáljanak vagy eldöntsék, hová menjenek. Ebben a listában a linkszöveg a körülvevő kontextusától megfosztva jelenik meg. Egy „kattintson ide”, „olvasson tovább” és „tudjon meg többet” kifejezésekkel teli üzenet haszontalan leltárt hoz létre azonos, értelmetlen bejegyzésekből. Minden link szövegének önmagában is értelmesnek kell lennie: a „Olvassa el tavaszi fenntarthatósági jelentésünket” vagy a „Kövesse nyomon rendelését” pontosan megmondja a felhasználónak, hová vezet a link, bármilyen körülvevő mondat nélkül.

Ugyanez vonatkozik a gombokra is, amelyek az e-mailben általában gombnak látszó stílusú linkek — gyakran a „golyóálló gomb” technikával építve, egymásba ágyazott táblázatok és háttérszínek használatával, hogy a kliensekben megjelenjenek. Bármi is legyen a szerkezet, a gomb akadálymentes nevének le kell írnia a műveletét. Egy üres vagy homályos gomb, vagy olyan, amelynek szövege csak egy háttérképben él, zsákutca a segítő technológia számára. Ha a gomb képalapú, a művelet a kép alt szövegébe tartozik.

Tegye a link- és gombcélpontokat elég nagyra a kényelmes megérintéshez — a WCAG 2.2 bevezetett egy minimális célpontméretet, és mobilon egy túl kicsi érintési célpont mindenkit frusztrál, nemcsak a motoros fogyatékossággal élő felhasználókat. Gondoskodjon arról, hogy a linkek ne csak szín alapján legyenek megkülönböztethetők, mert a csak színnel jelölt linkek megbuknak a gyengénlátó vagy színvak felhasználók számára; az aláhúzás a legbiztonságosabb jelzés. És adjon minden linknek valódi, működő célpontot egy helykitöltő helyett. A homályos linkszöveg az egyik leggyakoribb hiba, amit látunk, és a weben is megjelenik, nemcsak az e-mailben — összefoglalónk a kerülendő gyakori akadálymentesítési problémákról ugyanezt a mintát fedi le szélesebb kontextusban.

A preheader és az előnézeti élmény

A preheader — néha előnézeti szövegnek nevezik — az a szövegrészlet, amely a tárgysor mellett vagy alatt jelenik meg a beérkezett üzenetek között, mielőtt az üzenetet megnyitnák. Sok e-mail elpazarolja ezt, és arra hagyja, hogy alapértelmezésben az legyen, ami történetesen elsőként jön: egy „Az e-mail nem jelenik meg megfelelően?” sor, egy „leiratkozás” link vagy egy üres alt szövegekből álló sorozat. A beérkezett üzeneteik között navigáló képernyőolvasó-felhasználók számára, és mindenki számára, aki azon dönt, hogy megnyissa-e, az az elpazarolt preheader egy elszalasztott lehetőség a kommunikációra.

Írjon szándékos, értelmes preheadert, amely összefoglalja az e-mail célját, és helyezze el a törzs első szöveges tartalmaként, hogy ez legyen az, amit a beérkezett üzenetek listája felvesz. A szokásos technika egy rejtett szövegblokk az e-mail teteje közelében, vizuálisan rejtettre stílusozva, de a kliensek és a segítő technológia számára továbbra is elérhetően. Legyen óvatos azzal, hogyan rejti el: egy rosszul elrejtett preheader vagy nemkívánatos látható sorként jelenhet meg, vagy a képernyőolvasók teljesen kihagyhatják. Töltse ki megfelelően, hogy a beérkezett üzenetek záró tartalma ne szivárogtasson szomszédos szöveget az előnézetbe.

Kezelje a preheadert az üzenet információs architektúrájának részeként. Egy világos tárgysorral és egy erős nyitócímsorral kombinálva minden címzettnek — látónak vagy sem — gyors, pontos képet ad arról, hogy mi az e-mail és miért fontos.

Reszponzív elrendezés és nagyítás

Az e-maileket ugyanúgy olvassák telefonon, mint asztali számítógépen, és olyan emberek olvassák, akik ránagyítanak, hogy nagyobbra állítsák a szöveget. Mindkettő megköveteli, hogy az elrendezés alkalmazkodjon. Egy rögzített, széles elrendezés, amely vízszintes görgetésre kényszerít egy kis képernyőn, vagy amely eltörik, amikor a felhasználó növeli a szövegméretet, akadály — és a WCAG 2.2-nek van kritériuma mind az újratördelésre, mind a szövegközökre, amelyek itt érvényesek.

Építsen reszponzív e-maileket: egy egyoszlopos elrendezés a keskeny képernyőkön szinte mindig a legrobusztusabb és legakadálymentesebb választás, mert megőrzi az olvasási sorrendet, és elkerüli az egymás melletti tartalmat, amely kiszámíthatatlanul omlik össze. Ahol médialekérdezéseket használ az elrendezések váltására, ne feledje, hogy egyes kliensek figyelmen kívül hagyják azokat, így az alapértelmezett megjelenítésnek továbbra is használhatónak kell lennie. Állítsa a betűméreteket elég nagyra a nagyítás nélküli olvasáshoz — a nagyjából 14–16 pixel alatti törzsszöveg sok ember számára nehéz mobilon — és kerülje a sormagasság vagy a betűköz olyan szoros rögzítését, hogy a megnagyobbított szöveg átfedjen vagy levágódjon.

Tesztelje, mi történik, amikor a felhasználó ránagyít vagy növeli az eszköze rendszerbetűméretét. A tartalomnak újra kell tördelődnie és olvashatónak kell maradnia, ahelyett hogy túlcsordulna a tárolóján vagy eltűnne más elemek mögött. A jutalom egy olyan e-mail, amely nemcsak a gyengénlátó felhasználók számára működik, hanem mindenki számára, aki kis képernyőn olvas tökéletlen körülmények között.

Tesztelés kliensek és képernyőolvasók között

Az e-mail akadálymentességét nem ellenőrizheti kizárólag a kód vizsgálatával, mert az egész kihívás abban rejlik, hogy a kliensek ugyanazt a kódot eltérően jelenítik meg. A tesztelésnek a kliensek és segítő technológiák reprezentatív mátrixán keresztül kell történnie, azokban a körülményekben, amelyeket a valódi címzettek használnak.

Fedje le minimum a főbb klienseket: Outlook (asztali Windowson, valamint a webes és új verziók), Gmail (web és mobilalkalmazás) és Apple Mail (macOS és iOS). Mindegyiknél ellenőrizze a megjelenítést világos és sötét módban egyaránt, bekapcsolt és kikapcsolt képekkel, és megnövelt nagyításnál. Aztán rétegezze rá a képernyőolvasókat — VoiceOver az Apple Maillel macOS-en és iOS-en, NVDA vagy JAWS az Outlookkal és Gmaillel Windowson, és TalkBack a Gmail alkalmazással Androidon. Hallgassa az e-mailt úgy, ahogy egy képernyőolvasót használó felhasználó tenné: bejelentik-e a címsorokat, logikus-e az olvasási sorrend, némák-e az elrendezési táblázatok, van-e értelmük a linkeknek a linklistában, bejelentenek-e a képek hasznos alt szöveget, vagy némák maradnak, amikor dekoratívak?

Az automatikus ellenőrzéseknek megvan a helyük — gyorsan megjelölhetik a hiányzó alt attribútumokat, az alacsony kontrasztot és a hiányzó nyelvi attribútumokat sok sablonon keresztül — de nem tudják megítélni, hogy az alt szöveg értelmes-e, hogy az olvasási sorrend a helyes történetet meséli-e el, vagy hogy egy gomb neve leírja-e a műveletét. Ez az ítélet manuális tesztelést igényel, ideális esetben olyan emberek általi tesztelést is, akik nap mint nap használnak segítő technológiát. Manuális akadálymentesítési auditok útmutatónk elmagyarázza, miért pótolhatatlan az emberi tesztelés, és fogyatékossággal élő személyek által végzett auditjaink pontosan ezt a megélt tapasztalati perspektívát hozzák az e-mailbe.

Egy figyelmeztetés: ne csábítsák el az akadálymentesítési „overlay” widgetek, amelyek azonnali megfelelőséget ígérnek. Nem működnek webhelyeknél, és irrelevánsak az e-mailnél, ahol nincs oldal, amelybe szkriptet lehetne befecskendezni. A valódi e-mail-akadálymentesség a jelölőkód javításából származik, nem egy rátett kiegészítőből.

Sablonok helyreállítása ESP-szinten

Egy e-mail javítása hasznos. Annak a forrásnak a javítása, amely minden e-mailt generál, átalakító erejű. A legtöbb szervezet egy e-mail-szolgáltatón keresztül küld — Mailchimp, Klaviyo, Salesforce Marketing Cloud, Braze és hasonlók — ahol a kampányok mestersablonokból, újrafelhasználható modulokból és fogd és vidd tartalomblokkokból állnak össze. Ha ezek az alapul szolgáló sablonok hordozzák az akadálymentesítési javításokat, minden jövőbeli küldés automatikusan örökli azokat, és a marketingcsapatnak nem kell minden kampányhoz egy ellenőrzőlistát fejben tartania.

Ez a legköltséghatékonyabb hely a befektetésre. Állítsa helyre a mestersablont úgy, hogy az elrendezési táblázatok role="presentation"-t hordozzanak, a nyelvi attribútum be legyen állítva, a preheader szerkezete a helyén legyen, és a címsorvázlat helyes legyen. Állítson helyre minden újrafelhasználható modult — a hero blokkot, a cikkkártyát, a gombot, a láblécet — hogy bármit is húz be a csapat, az szerkezetileg akadálymentes legyen. Hozzon létre mintákat az alt szöveghez, hogy a szerkesztők késztetést kapjanak a megírására, és süsse bele a kontrasztbiztos, sötét módot figyelembe vevő színeket a sablonok által használt márkapalettába.

A bökkenő az, hogy a fogd és vidd szerkesztők szintén visszacsúsztathatják az akadálymentességet: egy szerkesztő eltávolíthatja a role="presentation"-t, eltorzíthatja a jelölőkódot exportáláskor, vagy hagyhatja, hogy egy szerkesztő egy nem akadálymentes blokkot illesszen be. Így a sablonok helyreállítását párosítani kell irányítással — irányelvekkel, felülvizsgálati lépésekkel és időszakos újratesztelésssel, ahogy az ESP és annak exportviselkedése változik. Itt térül meg az, ha az akadálymentességet beépítjük a munkafolyamatba; akadálymentesítési folyamatfejlesztés szolgáltatásunk segít a csapatoknak abban, hogy az akadálymentes e-mailt alapértelmezetté tegyék, ne utógondolattá, és az akadálymentesítési tanácsadás összehangolja azt a szélesebb körű megfelelőségi programjával. Az Európai Akadálymentesítési Irányelv hatálya alá tartozó szervezetek számára az akadálymentes ügyfélkommunikáció része a képnek, amit EAA-megfelelőségi áttekintésünk fejt ki.

A QualiBooth kombinálja az akadálymentesítési szkennelő szoftvert azokhoz a problémákhoz, amelyeket a gépek megbízhatóan elkapnak, a szakértői manuális helyreállítással azokhoz a megítélést igénylő döntésekhez, amelyeket nem tudnak — webhelyeken, dokumentumokon és e-mailen egyaránt. Ha az e-mailjei részei annak, ahogyan az ügyfeleit kiszolgálja, ugyanazt a szigort érdemlik, mint a digitális vagyonának többi része.

Összegzés

Az e-mailek akadálymentesítése nem a webes akadálymentesítés kisebb változata — kapcsolódó, de eltérő szakterület, amelyet egy széttöredezett klienstáj, táblázat-alapú elrendezések és olyan megjelenítőmotorok formálnak, amelyek a modern web nagy részét figyelmen kívül hagyják. A jó hír az, hogy a technikák jól megalapozottak: szemantikus szerkezet és egy ép címsorvázlat, role="presentation" minden elrendezési táblázaton, értelmes alt szöveg üres alttal a dekorációhoz, kontraszt, amely túléli a sötét módot, önmagukat leíró linkek és gombok, egy szándékos preheader, reszponzív elrendezések, amelyek kibírják a nagyítást, és fegyelmezett tesztelés kliensek és képernyőolvasók között. Alkalmazza ezeket sablonszinten, és az akadálymentesség megszűnik kampányonkénti robot lenni, és a rendszere tulajdonságává válik.

A megtérülés valós. Az akadálymentes e-mailek több embert érnek el, kikapcsolt képekkel is világosan olvashatók, és általában jobban teljesítenek, mert a világosság és a robusztusság mindenkinek segít. Ha segítségre van szüksége, e-mail-helyreállítási szolgáltatásunk auditálhatja a sablonjait, javíthatja azokat ESP-szinten, és ellenőrizheti az eredményt a teljes kliensmátrixon — és kérhet egy demót vagy futtathat egy ingyenes szkennelést a webhelyén, hogy lássa, hol áll a digitális vagyonának többi része.

Gyakran ismételt kérdések

Tényleg szükségem van role="presentation"-re minden elrendezési táblázaton? Igen. Nélküle a képernyőolvasók minden elrendezési táblázatot adattáblázatként jelentenek be, felolvassák a sor- és oszlopszámokat, és megzavarják a folyamot. Mivel az e-mail-elrendezések egymásba ágyazzák a táblázatokat, az attribútumnak minden elrendezési táblázaton rajta kell lennie, nemcsak a külső burkolón. A valódi adattáblázatok, mint a nyugták, ehelyett megtartják az adatszemantikájukat.

Mit tegyek egy dekoratív kép alt szövegébe? Használjon üres alt attribútumot, alt="" formában írva, hogy a képernyőolvasók kihagyják a képet. Ne hagyja el teljesen az attribútumot, mert egy hiányzó alt gyakran azt eredményezi, hogy a kép fájlnevét vagy URL-jét hangosan felolvassák.

Hogyan akadályozhatom meg, hogy a sötét mód tönkretegye az e-mailemet? Nem tudja teljesen kontrollálni, hogy az egyes kliensek hogyan kezelik a sötét módot, de tervezhet védekezőn: kerülje a tiszta feketét és fehéret, adjon a logóknak kontrasztos hátteret vagy körvonalat, tartsa a kontrasztot a WCAG 2.2 küszöbök felett, és tesztelje a megjelenített eredményt sötét módban minden főbb kliensben, ahelyett hogy feltételezné, hogy a világos módú tervezése átvitel marad.

Akadálymentessé tehet egy automatikus eszköz az e-mailemet? Az automatikus eszközök elkapnak néhány problémát — hiányzó alt attribútumok, alacsony kontraszt, hiányzó nyelvi beállítások — de nem tudják megítélni, hogy az alt szöveg értelmes-e, hogy az olvasási sorrendnek van-e értelme, vagy hogy a linkek és gombok leírják-e a céljukat. Ez manuális tesztelést igényel képernyőolvasókkal. Az akadálymentesítési overlay widgetek nem megoldás, és nem alkalmazhatók az e-mailre.

Jobb az egyes e-maileket vagy a sablonokat javítani? A sablonokat. A mestersablonok és újrafelhasználható modulok helyreállítása az ESP-ben azt jelenti, hogy minden jövőbeli küldés örökli a javításokat, ami sokkal költséghatékonyabb, mint a kampányokat egyenként javítani. Párosítsa irányítással, hogy a fogd és vidd szerkesztők ne vezessék be újra a problémákat.