Ghid de accesibilitate pentru email HTML

Pentru majoritatea organizațiilor, emailul este cel mai frecvent punct de contact pe care îl au cu clienții. O confirmare de comandă, o resetare de parolă, un extras lunar, un buletin informativ — aceste mesaje sosesc adesea cu mult înainte ca cineva să vă viziteze site-ul web și sosesc mult mai des. Totuși, accesibilitatea emailurilor este unul dintre cele mai neglijate colțuri ale incluziunii digitale. Echipele care investesc masiv într-un site web accesibil trimit în mod obișnuit campanii construite pe markup încâlcit, conținut format doar din imagini și butoane care sună ca „faceți clic aici” pentru un cititor de ecran.

Motivul este parțial istoric și parțial tehnic: emailul HTML este o disciplină proprie, cu propriile constrângeri, propriile motoare de randare și propriile moduri de eșec. Tehnicile care sunt fireşti pe web-ul modern — landmark-uri semantice, layouturi flexbox, proprietăți personalizate CSS — sunt nesigure sau de-a dreptul defecte în matricea clienților de email. A face un email accesibil nu este aceeași muncă ca a face o pagină web accesibilă, iar tratarea lor ca fiind identice este exact motivul pentru care atât de multe emailuri eșuează.

Acest ghid parcurge ce necesită cu adevărat accesibilitatea emailurilor: cum să structurați markupul astfel încât tehnologia asistivă să-l poată analiza, cum să gestionați tabelele de prezentare care încă susțin layoutul de email, cum să scrieți text alternativ și linkuri care au sens în afara contextului, cum să supraviețuiți modului întunecat și zoomului și cum să testați rezultatul în Outlook, Gmail, Apple Mail și cititoare de ecran. Dacă preferați ca specialiștii să facă acest lucru pentru șabloanele dvs., serviciul nostru de remediere a emailurilor acoperă întregul stack.

De ce emailul HTML este o disciplină proprie

O pagină web se randează într-un browser. Există un număr restrâns de browsere principale, ele se actualizează după calendare previzibile și converg către standardele web. Emailul este opusul. Mesajul dvs. poate fi deschis în zeci de clienți — Outlook pe Windows, Outlook pe web, noul Outlook, Gmail într-un browser, aplicația Gmail, Apple Mail pe macOS și iOS, Yahoo, Samsung Email și multe altele — fiecare cu un motor de randare diferit și un subset diferit, adesea în scădere, de HTML și CSS acceptate.

Cel mai notoriu exemplu este Outlook desktop pe Windows, care din punct de vedere istoric randa emailurile folosind motorul Microsoft Word în loc de un motor de browser real. Doar acest lucru îi obligă pe dezvoltatorii de email să se întoarcă la layouturi bazate pe tabele, stiluri inline și tipare defensive pe care web-ul le-a abandonat acum ani de zile. Mulți clienți elimină de asemenea blocurile <style>, refuză CSS-ul modern și rescriu atributele pe care le consideră nesigure.

Pentru accesibilitate, acest lucru contează enorm. HTML-ul semantic pe care vă bazați pentru un site web — <nav>, <main>, landmark-uri ARIA — este frecvent eliminat sau ignorat în email. Nu vă puteți baza pe o singură țintă de randare. Accesibilitatea emailurilor înseamnă, prin urmare, construirea de mesaje care se degradează grațios: care rămân lizibile, navigabile și semnificative chiar și atunci când layoutul se prăbușește, imaginile nu se încarcă sau stilurile sunt eliminate. Această mentalitate defensivă este fundamentul pe care se construiește tot restul din acest ghid și este motivul pentru care emailul aparține unui program dedicat de servicii de accesibilitate în loc să fie inclus în munca web generală.

Structură semantică și o ordine de citire logică

Chiar și cu toate constrângerile, cel mai valoros lucru pe care îl puteți face pentru un utilizator de cititor de ecran este să oferiți emailului o structură clară, liniară. Cititoarele de ecran citesc conținutul în ordinea DOM, așa că ordinea markupului dvs. este ordinea în care este auzit mesajul dvs. Dacă designul dvs. plasează un banner promoțional înaintea mesajului propriu-zis, bannerul este anunțat primul — indiferent de cum arată layoutul.

Folosiți elemente de titlu reale pentru a stabili ierarhia. Un email ar trebui să aibă un titlu logic de nivel superior (de obicei subiectul sau oferta principală) ca <h1>, cu secțiunile ulterioare marcate ca <h2> și <h3>. Utilizatorii de cititoare de ecran navighează după titlu pentru a scana un mesaj, așa că un contur bine structurat transformă un zid de text în ceva ce poate fi parcurs rapid. Nu falsificați titlurile cu text <span> mare și îngroșat; vizual poate arăta ca un titlu, dar tehnologia asistivă aude text de corp obișnuit. La fel, folosiți markup de listă autentic (<ul>, <ol>, <li>) pentru liste și setați limba documentului cu un atribut lang pe elementul <html> astfel încât cititoarele de ecran să folosească pronunția și vocea corecte.

Ordinea de citire trebuie de asemenea să aibă sens în sine. Citiți markupul de sus în jos, ignorând toate stilurile, și întrebați-vă dacă încă spune o poveste coerentă. Dacă da, aveți un fundament solid. Dacă sensul depinde de aranjamentul vizual, aveți de lucru — iar acea muncă începe de obicei cu tabelele de layout.

Tabele de prezentare și role=“presentation”

Layoutul de email este construit cu tabele. Aceasta nu este o alegere stilistică; este o cerință de supraviețuire, deoarece layoutul bazat pe tabele este singura abordare care se randează consecvent în matricea de clienți. Problema este că tabelele poartă semnificație semantică. În mod implicit, un cititor de ecran anunță un <table> ca tabel de date, citește numărul de rânduri și coloane și încearcă să asocieze celulele cu antetele. Pentru un tabel care există pur și simplu pentru a poziționa un logo lângă un titlu, acel anunț este zgomot — iar într-un email cu tabele imbricate și multiple devine o experiență epuizantă și dezorientantă.

Soluția este să spuneți tehnologiei asistive că aceste tabele sunt schele de layout, nu date. Adăugați role="presentation" la fiecare tabel folosit pentru layout: <table role="presentation">. Acest lucru elimină semantica tabelului astfel încât cititoarele de ecran să sară peste anunțurile de rânduri/coloane și pur și simplu să citească conținutul din interior în ordine. Este una dintre cele mai importante și mai frecvent omise tehnici din accesibilitatea emailurilor și trebuie aplicată la fiecare tabel de layout, inclusiv la cele imbricate, nu doar la wrapperul exterior.

Câteva practici conexe consolidează acest lucru. Nu adăugați summary, celule de antet <th>, scope sau <caption> la tabelele de prezentare — acela este markup purtător de semnificație rezervat pentru tabelele de date autentice. Dacă emailul dvs. conține date tabelare reale, cum ar fi o chitanță detaliată, faceți opusul: lăsați-l ca tabel de date cu antete <th> corecte și atribute scope astfel încât relațiile să fie transmise. Principiul este consecvența între aspect și semantică. A face acest lucru corect într-o bibliotecă de șabloane este migălos și ușor de regresat, motiv pentru care este o parte centrală a muncii noastre de remediere a emailurilor.

Imagini și text alternativ

Imaginile poartă multă greutate în email, iar mulți destinatari le văd cu imaginile dezactivate în mod implicit — unii clienți blochează imaginile la distanță până când utilizatorul își dă acordul. Acest lucru face textul alternativ de două ori mai important: este atât o cerință de accesibilitate, cât și rezerva care vă menține mesajul inteligibil când imaginile nu se încarcă.

Fiecare element <img> are nevoie de un atribut alt. Ce introduceți în el depinde de scopul imaginii. Pentru o imagine informativă — o fotografie de produs, un infografic, un grafic — textul alternativ ar trebui să transmită aceeași informație pe care o oferă imaginea. „Pantof de alergare albastru, vedere laterală” este mai util decât „image1.png”, iar textul alternativ al unui grafic ar trebui să rezume concluzia, nu doar să-l eticheteze ca grafic. Pentru text randat ca imagine, ceea ce încă se întâmplă cu titlurile promoționale, textul alternativ trebuie să reproducă cuvintele exact, deoarece altfel acel conținut este invizibil pentru cititoarele de ecran și pentru oricine are imaginile dezactivate.

Pentru imagini decorative — spacere, ornamente de fundal, separatoare care nu adaugă nimic la sens — folosiți un atribut alt gol, scris ca alt="". Acest lucru spune explicit cititoarelor de ecran să sară peste imagine în loc să anunțe un nume de fișier. Omiterea completă a atributului nu este același lucru; un alt lipsă face adesea cititoarele de ecran să citească URL-ul imaginii, ceea ce este cel mai rău din ambele lumi. Fiți deosebit de atenți cu tiparul comun de utilizare a unei imagini ca buton sau link: textul alternativ al acelei imagini trebuie să descrie acțiunea, cum ar fi „Finalizați achiziția”, nu imaginea.

Încă un punct specific emailului: nu puneți niciodată informații esențiale doar într-o imagine. Un cod de cupon, un număr de confirmare, un link de dezabonare, îndemnul principal la acțiune — dacă oricare dintre acestea există doar ca pixeli, dispar pentru utilizatorii cu imaginile dezactivate și utilizatorii de cititoare de ecran. Păstrați conținutul critic ca text viu, selectabil.

Contrast și mod întunecat

Textul trebuie să fie lizibil, ceea ce înseamnă că trebuie să îndeplinească cerințele de contrast. WCAG 2.2 cere un raport de contrast de cel puțin 4.5:1 pentru text normal și 3:1 pentru text mare față de fundalul său. Textul gri deschis pe un fundal alb — un favorit peren al designului minimalist de email — eșuează frecvent, la fel ca butoanele palide și culorile de link cu contrast scăzut. Aceste praguri se aplică emailului la fel ca web-ului, iar aceleași criterii de succes WCAG 2.2 sunt reperul; prezentarea noastră generală mai amplă privind conformitatea WCAG explică cum se îmbină aceste criterii.

Emailul adaugă o complicație pe care web-ul în mare parte nu o are: modul întunecat. Mulți clienți — Apple Mail, Outlook și Gmail printre ei — transformă automat emailurile când utilizatorul are modul întunecat activat. Unii pur și simplu schimbă fundalul; alții inversează sau recolorează agresiv paleta dvs., uneori parțial. Rezultatul este că un buton cu text închis pe o culoare de marcă deschisă poate ajunge cu text închis pe un fundal închis inversat, reducând contrastul la zero. Textul negru într-o casetă colorată poate deveni invizibil. Logo-urile cu fundaluri transparente pot dispărea pe o pânză întunecată.

Nu există un control universal asupra modului întunecat, iar tehnicile care există variază în funcție de client, dar principiile defensive sunt stabile. Proiectați cu ambele moduri în minte. Evitați negrul pur sau albul pur ca culori de bază, deoarece nu lasă loc clientului să se ajusteze. Oferiți logo-urilor și graficelor cheie un contur contrastant sau o placă de fundal solidă astfel încât să supraviețuiască inversării. Testați rezultatul efectiv randat în modul întunecat în fiecare client major în loc să aveți încredere că designul dvs. de mod luminos se va traduce. Scopul este ca textul și elementele interactive să rămână peste pragul de contrast indiferent de cum le inversează clientul.

Linkuri descriptive și butoane accesibile

Utilizatorii de cititoare de ecran afișează adesea o listă cu toate linkurile dintr-un mesaj pentru a naviga sau a decide unde să meargă. În acea listă, textul linkului apare lipsit de contextul înconjurător. Un mesaj plin de „Faceți clic aici”, „Citiți mai mult” și „Aflați mai multe” produce un inventar inutil de intrări identice, fără sens. Textul fiecărui link ar trebui să aibă sens în sine: „Citiți raportul nostru de sustenabilitate de primăvară” sau „Urmăriți comanda dvs.” îi spune utilizatorului exact unde duce linkul fără nicio propoziție înconjurătoare.

Același lucru se aplică butoanelor, care în email sunt de obicei linkuri stilizate să arate ca butoane — adesea construite cu tehnica „buton antiglonț” folosind tabele imbricate și culori de fundal astfel încât să se randeze în toți clienții. Indiferent de construcție, numele accesibil al butonului trebuie să descrie acțiunea sa. Un buton gol sau vag, sau unul al cărui text trăiește doar într-o imagine de fundal, este o fundătură pentru tehnologia asistivă. Dacă butonul se bazează pe imagine, acțiunea aparține textului alternativ al imaginii.

Faceți țintele de linkuri și butoane suficient de mari pentru a fi atinse confortabil — WCAG 2.2 a introdus o dimensiune minimă a țintei, iar pe mobil o țintă tactilă prea mică frustrează pe toată lumea, nu doar pe utilizatorii cu dizabilități motorii. Asigurați-vă că linkurile se disting prin mai mult decât doar culoare, deoarece linkurile bazate doar pe culoare eșuează pentru utilizatorii cu vedere slabă sau daltonism; o subliniere este indiciul cel mai sigur. Și oferiți fiecărui link o destinație reală, funcțională în loc de un placeholder. Textul de link vag este una dintre cele mai frecvente eșecuri pe care le vedem și apare și pe web, nu doar în email — sinteza noastră a problemelor frecvente de accesibilitate de evitat acoperă același tipar într-un context mai larg.

Preheaderul și experiența de previzualizare

Preheaderul — numit uneori text de previzualizare — este fragmentul de text care apare lângă sau sub linia de subiect în inbox, înainte ca mesajul să fie deschis. Multe emailuri îl irosesc, lăsându-l să recurgă la orice text vine întâmplător primul: o linie „Emailul nu se afișează corect?”, un link de „dezabonare” sau un șir de text alternativ gol. Pentru utilizatorii de cititoare de ecran care navighează prin inbox și pentru toți cei care decid dacă să-l deschidă, acel preheader irosit este o ocazie ratată de a comunica.

Scrieți un preheader deliberat, semnificativ care rezumă scopul emailului și plasați-l ca primul conținut de text din corp astfel încât să fie ceea ce preia inboxul. Tehnica standard este un bloc de text ascuns aproape de partea de sus a emailului, stilizat să fie ascuns vizual, dar încă disponibil pentru clienți și tehnologia asistivă. Aveți grijă cum îl ascundeți: un preheader prost ascuns poate fie să apară ca o linie vizibilă nedorită, fie să fie omis complet de cititoarele de ecran. Completați-l corespunzător astfel încât conținutul ulterior din inbox să nu scurgă text adiacent în previzualizare.

Tratați preheaderul ca parte a arhitecturii informaționale a mesajului. Combinat cu o linie de subiect clară și un titlu de deschidere puternic, oferă fiecărui destinatar — văzător sau nu — o senzație rapidă și precisă a ceea ce este emailul și de ce contează.

Layout responsiv și zoom

Emailurile sunt citite pe telefoane la fel de mult ca pe desktopuri și sunt citite de oameni care fac zoom pentru a mări textul. Ambele cer ca layoutul să se adapteze. Un layout fix, lat care forțează derularea orizontală pe un ecran mic, sau care se sparge când un utilizator mărește dimensiunea textului, este o barieră — iar WCAG 2.2 are criterii atât pentru reflow, cât și pentru spațierea textului care se aplică aici.

Construiți emailurile să fie responsive: un layout pe o singură coloană pe ecrane înguste este aproape întotdeauna alegerea cea mai robustă și accesibilă, deoarece păstrează ordinea de citire și evită conținutul alăturat care se prăbușește imprevizibil. Acolo unde folosiți media queries pentru a comuta layouturile, rețineți că unii clienți le ignoră, așa că randarea implicită trebuie să rămână utilizabilă. Setați dimensiuni de font suficient de mari pentru a fi citite fără zoom — textul de corp sub aproximativ 14 până la 16 pixeli este dificil pentru mulți oameni pe mobil — și evitați fixarea înălțimii de rând sau a spațierii literelor atât de strâns încât textul mărit să se suprapună sau să fie tăiat.

Testați ce se întâmplă când un utilizator face zoom sau mărește dimensiunea fontului de sistem al dispozitivului său. Conținutul ar trebui să se refluxeze și să rămână lizibil în loc să-și depășească containerul sau să dispară în spatele altor elemente. Recompensa este un email care funcționează nu doar pentru utilizatorii cu vedere slabă, ci pentru toți cei care citesc pe un ecran mic în condiții imperfecte.

Testarea în clienți și cititoare de ecran

Nu puteți verifica accesibilitatea emailurilor inspectând doar codul, deoarece întreaga provocare este că clienții randează același cod diferit. Testarea trebuie să se desfășoare într-o matrice reprezentativă de clienți și tehnologii asistive, în condițiile pe care le folosesc destinatarii reali.

Acoperiți cel puțin clienții majori: Outlook (desktop pe Windows, plus versiunile web și noi), Gmail (web și aplicația mobilă) și Apple Mail (macOS și iOS). Pentru fiecare, verificați randarea atât în mod luminos, cât și întunecat, cu imaginile activate și dezactivate, și la zoom mărit. Apoi suprapuneți cititoare de ecran — VoiceOver cu Apple Mail pe macOS și iOS, NVDA sau JAWS cu Outlook și Gmail pe Windows, și TalkBack cu aplicația Gmail pe Android. Ascultați emailul așa cum ar face-o un utilizator de cititor de ecran: sunt anunțate titlurile, este logică ordinea de citire, sunt tăcute tabelele de layout, au sens linkurile în lista de linkuri, anunță imaginile text alternativ util sau rămân tăcute când sunt decorative?

Verificările automate au locul lor — pot semnala rapid atribute alt lipsă, contrast scăzut și atribute de limbă absente în multe șabloane — dar nu pot judeca dacă textul alternativ este semnificativ, dacă ordinea de citire spune povestea corectă, sau dacă numele unui buton descrie acțiunea sa. Această judecată necesită testare manuală, ideal incluzând testarea de către persoane care folosesc tehnologie asistivă în fiecare zi. Ghidul nostru de auditări manuale de accesibilitate explică de ce testarea umană este de neînlocuit, iar auditările noastre realizate de persoane cu dizabilități aduc exact acea perspectivă a experienței trăite în email.

O avertizare: nu vă lăsați tentați de widgeturile de „suprapunere” de accesibilitate care promit conformitate instantanee. Nu funcționează pentru site-uri web și sunt irelevante pentru email, unde nu există nicio pagină în care să injectați un script. Accesibilitatea reală a emailurilor vine din corectarea markupului, nu dintr-un adaos.

Remedierea șabloanelor la nivel de ESP

Corectarea unui email este utilă. Corectarea sursei care generează fiecare email este transformatoare. Majoritatea organizațiilor trimit printr-un furnizor de servicii de email — Mailchimp, Klaviyo, Salesforce Marketing Cloud, Braze și altele asemenea — unde campaniile sunt asamblate din șabloane master, module reutilizabile și blocuri de conținut de tip drag-and-drop. Dacă aceste șabloane subiacente poartă corecturile de accesibilitate, fiecare trimitere viitoare le moștenește automat, iar echipa de marketing nu trebuie să-și amintească o listă de verificare pentru fiecare campanie.

Acesta este locul cel mai rentabil pentru a investi. Remediați șablonul master astfel încât tabelele de layout să poarte role="presentation", atributul de limbă să fie setat, structura preheaderului să fie la locul ei și schela de titluri să fie corectă. Remediați fiecare modul reutilizabil — blocul hero, cardul de articol, butonul, subsolul — astfel încât tot ce trage echipa în el să fie accesibil prin construcție. Stabiliți tipare pentru textul alternativ astfel încât editorii să fie îndemnați să-l scrie și încorporați culori sigure pentru contrast și conștiente de modul întunecat în paleta de marcă pe care o folosesc șabloanele.

Capcana este că generatoarele drag-and-drop pot, de asemenea, regresa accesibilitatea: un generator poate elimina role="presentation", poate deteriora markupul la export, sau poate lăsa un editor să lipească un bloc inaccesibil. Așa că remedierea șabloanelor trebuie asociată cu guvernanță — orientări, pași de revizuire și retestare periodică pe măsură ce ESP-ul și comportamentul său de export se schimbă. Acolo merită încorporarea accesibilității în fluxul de lucru; serviciul nostru de îmbunătățire a procesului de accesibilitate ajută echipele să facă din emailul accesibil norma în loc de o idee ulterioară, iar consultanța de accesibilitate o aliniază cu programul dvs. mai larg de conformitate. Pentru organizațiile aflate sub European Accessibility Act, comunicările accesibile cu clienții fac parte din tablou, ceea ce expune prezentarea noastră generală privind conformitatea EAA.

QualiBooth combină software de scanare a accesibilității pentru problemele pe care mașinile le detectează fiabil cu remediere manuală expertă pentru deciziile pe care nu le pot lua — în site-uri web, documente și email deopotrivă. Dacă emailurile dvs. fac parte din modul în care vă serviți clienții, merită aceeași rigoare ca restul patrimoniului dvs. digital.

Concluzie

Accesibilitatea emailurilor nu este o versiune mai mică a accesibilității web — este o disciplină înrudită, dar distinctă, modelată de un peisaj de clienți fragmentat, layouturi bazate pe tabele și motoare de randare care ignoră mare parte din web-ul modern. Vestea bună este că tehnicile sunt bine stabilite: structură semantică și un contur de titluri solid, role="presentation" la fiecare tabel de layout, text alternativ semnificativ cu alt gol pentru decorare, contrast care supraviețuiește modului întunecat, linkuri și butoane care se descriu singure, un preheader deliberat, layouturi responsive care rezistă zoomului și testare disciplinată în clienți și cititoare de ecran. Aplicați-le la nivel de șablon și accesibilitatea încetează să fie o corvoadă pentru fiecare campanie și devine o proprietate a sistemului dvs.

Câștigul este real. Emailurile accesibile ajung la mai mulți oameni, se citesc clar cu imaginile dezactivate și tind să performeze mai bine deoarece claritatea și robustețea ajută pe toată lumea. Dacă doriți ajutor, serviciul nostru de remediere a emailurilor vă poate audita șabloanele, le poate corecta la nivel de ESP și poate verifica rezultatul în întreaga matrice de clienți — și puteți solicita o demonstrație sau rula o scanare gratuită a site-ului dvs. web pentru a vedea unde se află restul patrimoniului dvs. digital.

Întrebări frecvente

Am într-adevăr nevoie de role="presentation" la fiecare tabel de layout? Da. Fără el, cititoarele de ecran anunță fiecare tabel de layout ca tabel de date, citind numărul de rânduri și coloane și perturbând fluxul. Deoarece layouturile de email imbrică tabele, atributul trebuie să fie la fiecare tabel de layout, nu doar la wrapperul exterior. Tabelele de date autentice, precum chitanțele, își păstrează în schimb semantica de date.

Ce ar trebui să pun în textul alternativ pentru o imagine decorativă? Folosiți un atribut alt gol, scris alt="", astfel încât cititoarele de ecran să sară peste imagine. Nu omiteți complet atributul, deoarece un alt lipsă face adesea ca numele de fișier sau URL-ul imaginii să fie citit cu voce tare.

Cum împiedic modul întunecat să-mi strice emailul? Nu puteți controla complet cum gestionează fiecare client modul întunecat, dar puteți proiecta defensiv: evitați negrul și albul pur, oferiți logo-urilor un fundal sau contur contrastant, mențineți contrastul peste pragurile WCAG 2.2 și testați rezultatul randat în modul întunecat în fiecare client major în loc să presupuneți că designul dvs. de mod luminos se va transfera.

Poate un instrument automat să-mi facă emailul accesibil? Instrumentele automate detectează unele probleme — atribute alt lipsă, contrast scăzut, setări de limbă absente — dar nu pot judeca dacă textul alternativ este semnificativ, dacă ordinea de citire are sens, sau dacă linkurile și butoanele își descriu scopul. Acest lucru necesită testare manuală cu cititoare de ecran. Widgeturile de suprapunere de accesibilitate nu sunt o soluție și nu se aplică emailului.

Este mai bine să corectez emailuri individuale sau șabloane? Șabloane. Remedierea șabloanelor master și a modulelor reutilizabile în ESP-ul dvs. înseamnă că fiecare trimitere viitoare moștenește corecturile, ceea ce este mult mai rentabil decât corectarea campaniilor una câte una. Asociați-o cu guvernanță astfel încât generatoarele drag-and-drop să nu reintroducă probleme.