Guia d'accessibilitat de correu electrònic HTML

Per a la majoria d’organitzacions, el correu electrònic és el punt de contacte més freqüent que tenen amb els clients. Una confirmació de comanda, un restabliment de contrasenya, un extracte mensual, un butlletí — aquests missatges sovint arriben molt abans que algú visiti el vostre lloc web, i arriben molt més sovint. Tot i això, l’accessibilitat del correu electrònic és un dels racons més oblidats de la inclusió digital. Els equips que inverteixen molt en un lloc web accessible envien rutinàriament campanyes construïdes sobre marcatge embullat, contingut només d’imatges i botons que un lector de pantalla llegeix com a «feu clic aquí».

El motiu és en part històric i en part tècnic: el correu electrònic HTML és una disciplina pròpia, amb les seves pròpies restriccions, els seus propis motors de renderització i les seves pròpies maneres de fallar. Les tècniques que són naturals al web modern — landmarks semàntics, dissenys flexbox, propietats personalitzades CSS — són poc fiables o directament trencades a tota la matriu de clients de correu. Fer un correu accessible no és la mateixa feina que fer una pàgina web accessible, i tractar-los com a idèntics és exactament per què tants correus fallen.

Aquesta guia recorre què requereix realment l’accessibilitat del correu electrònic: com estructurar el marcatge perquè la tecnologia d’assistència el pugui analitzar, com gestionar les taules de presentació que encara sustenten el disseny del correu, com escriure text alternatiu i enllaços que tinguin sentit fora de context, com sobreviure al mode fosc i al zoom, i com provar el resultat a Outlook, Gmail, Apple Mail i lectors de pantalla. Si preferiu que especialistes ho facin per a les vostres plantilles, el nostre servei de reparació de correu electrònic cobreix tota la pila.

Per què el correu electrònic HTML és una disciplina pròpia

Una pàgina web es renderitza en un navegador. Hi ha un grapat de navegadors principals, s’actualitzen en calendaris previsibles i convergeixen en els estàndards web. El correu electrònic és el contrari. El vostre missatge es pot obrir en desenes de clients — Outlook a Windows, Outlook al web, el nou Outlook, Gmail en un navegador, l’aplicació Gmail, Apple Mail a macOS i iOS, Yahoo, Samsung Email i molts més — cadascun amb un motor de renderització diferent i un subconjunt diferent, sovint minvant, de l’HTML i el CSS admesos.

L’exemple més notori és l’Outlook d’escriptori a Windows, que històricament renderitzava el correu utilitzant el motor de Microsoft Word en lloc d’un motor de navegador real. Això sol ja obliga els desenvolupadors de correu a tornar a dissenys basats en taules, estils en línia i patrons defensius que el web va abandonar fa anys. Molts clients també eliminen els blocs <style>, rebutgen el CSS modern i reescriuen els atributs que consideren insegurs.

Per a l’accessibilitat, això importa enormement. L’HTML semàntic en què confieu per a un lloc web — <nav>, <main>, landmarks ARIA — sovint s’elimina o s’ignora al correu. No podeu recolzar-vos en un únic objectiu de renderització. L’accessibilitat del correu electrònic tracta, per tant, de construir missatges que es degradin amb gràcia: que segueixin sent llegibles, navegables i significatius fins i tot quan el disseny col·lapsa, les imatges no es carreguen o els estils es descarten. Aquesta mentalitat defensiva és el fonament sobre el qual es construeix tota la resta d’aquesta guia, i és per què el correu pertany a un programa dedicat de serveis d’accessibilitat en lloc de plegar-se a la feina web general.

Estructura semàntica i un ordre de lectura lògic

Fins i tot amb totes les restriccions, la cosa més valuosa que podeu fer per a un usuari de lector de pantalla és donar al correu una estructura clara i lineal. Els lectors de pantalla llegeixen el contingut en ordre DOM, de manera que l’ordre del vostre marcatge és l’ordre en què s’escolta el vostre missatge. Si el vostre disseny col·loca un bàner promocional abans del missatge real, el bàner s’anuncia primer — independentment de com es vegi el disseny.

Utilitzeu elements d’encapçalament reals per establir la jerarquia. Un correu hauria de tenir un encapçalament lògic de nivell superior (normalment el tema o l’oferta principal) com a <h1>, amb les seccions posteriors marcades com a <h2> i <h3>. Els usuaris de lectors de pantalla naveguen per encapçalament per escanejar un missatge, així que un esquema ben estructurat converteix un mur de text en una cosa fullejable. No falsifiqueu encapçalaments amb text <span> gran i en negreta; visualment pot semblar un encapçalament, però la tecnologia d’assistència sent text de cos ordinari. De la mateixa manera, utilitzeu marcatge de llista genuí (<ul>, <ol>, <li>) per a les llistes, i establiu l’idioma del document amb un atribut lang a l’element <html> perquè els lectors de pantalla utilitzin la pronunciació i la veu correctes.

L’ordre de lectura també ha de tenir sentit per si mateix. Llegiu el vostre marcatge de dalt a baix, ignorant tot l’estil, i pregunteu-vos si encara explica una història coherent. Si ho fa, teniu un fonament sòlid. Si el significat depèn de la disposició visual, teniu feina a fer — i aquesta feina sol començar amb les taules de disseny.

Taules de presentació i role=“presentation”

El disseny del correu electrònic es construeix amb taules. Això no és una elecció estilística; és un requisit de supervivència, perquè el disseny basat en taules és l’únic enfocament que es renderitza de manera consistent a tota la matriu de clients. El problema és que les taules tenen significat semàntic. Per defecte, un lector de pantalla anuncia una <table> com a taula de dades, llegeix el nombre de files i columnes, i intenta associar les cel·les amb encapçalaments. Per a una taula que existeix purament per col·locar un logotip al costat d’un titular, aquest anunci és soroll — i a través d’un correu amb taules imbricades i múltiples es converteix en una experiència esgotadora i desorientadora.

La solució és dir a la tecnologia d’assistència que aquestes taules són bastida de disseny, no dades. Afegiu role="presentation" a cada taula utilitzada per al disseny: <table role="presentation">. Això elimina la semàntica de la taula perquè els lectors de pantalla ometin els anuncis de fila/columna i simplement llegeixin el contingut de dins en ordre. És una de les tècniques més importants i més freqüentment oblidades de l’accessibilitat del correu electrònic, i s’ha d’aplicar a cada taula de disseny, incloses les imbricades, no només al contenidor més extern.

Algunes pràctiques relacionades reforcen això. No afegiu summary, cel·les d’encapçalament <th>, scope ni <caption> a les taules de presentació — aquest és marcatge portador de significat reservat per a taules de dades genuïnes. Si el vostre correu conté dades tabulars reals, com ara un rebut detallat, feu el contrari: deixeu-ho com a taula de dades amb encapçalaments <th> adequats i atributs scope perquè es transmetin les relacions. El principi és la consistència entre l’aparença i la semàntica. Aconseguir-ho bé a través d’una biblioteca de plantilles és minuciós i fàcil de regressar, per això és una part central de la nostra feina de reparació de correu electrònic.

Imatges i text alternatiu

Les imatges tenen molt pes al correu electrònic, i molts destinataris les veuen amb les imatges desactivades per defecte — alguns clients bloquegen les imatges remotes fins que l’usuari hi consent. Això fa el text alternatiu doblement important: és alhora un requisit d’accessibilitat i el recurs alternatiu que manté el vostre missatge intel·ligible quan les imatges no es carreguen.

Cada element <img> necessita un atribut alt. El que hi va a dins depèn del propòsit de la imatge. Per a una imatge informativa — una foto de producte, una infografia, un gràfic — el text alternatiu hauria de transmetre la mateixa informació que ofereix la imatge. «Sabatilla de córrer blava, vista lateral» és més útil que «image1.png», i el text alternatiu d’un gràfic hauria de resumir la conclusió, no només etiquetar-lo com a gràfic. Per a text renderitzat com a imatge, cosa que encara passa amb els titulars promocionals, el text alternatiu ha de reproduir les paraules exactament, perquè altrament aquest contingut és invisible per als lectors de pantalla i per a qualsevol amb les imatges desactivades.

Per a imatges decoratives — espaiadors, ornaments de fons, separadors que no afegeixen res al significat — utilitzeu un atribut alt buit, escrit com a alt="". Això diu explícitament als lectors de pantalla que ometin la imatge en lloc d’anunciar un nom de fitxer. Ometre l’atribut completament no és el mateix; un alt absent sovint fa que els lectors de pantalla llegeixin l’URL de la imatge, que és el pitjor dels dos mons. Aneu amb especial compte amb el patró comú d’utilitzar una imatge com a botó o enllaç: el text alternatiu d’aquesta imatge ha de descriure l’acció, com ara «Completeu la vostra compra», no la imatge.

Un punt més específic del correu electrònic: mai poseu informació essencial només en una imatge. Un codi de cupó, un número de confirmació, un enllaç de cancel·lació de subscripció, la crida a l’acció principal — si algun d’aquests existeix només com a píxels, desapareixen per als usuaris amb les imatges desactivades i els usuaris de lectors de pantalla. Mantingueu el contingut crític com a text viu i seleccionable.

Contrast i mode fosc

El text ha de ser llegible, cosa que vol dir que ha de complir els requisits de contrast. WCAG 2.2 demana una relació de contrast d’almenys 4.5:1 per al text normal i 3:1 per al text gran respecte al seu fons. El text gris clar sobre un fons blanc — un favorit perenne del disseny minimalista de correu — sovint falla, i el mateix passa amb els botons pàl·lids i els colors d’enllaç de baix contrast. Aquests llindars s’apliquen al correu igual que al web, i els mateixos criteris d’èxit de WCAG 2.2 són el punt de referència; la nostra visió general més àmplia de compliment de WCAG explica com encaixen aquests criteris.

El correu afegeix una complicació que el web majoritàriament no té: el mode fosc. Molts clients — Apple Mail, Outlook i Gmail entre ells — transformen automàticament els correus quan l’usuari té el mode fosc activat. Alguns simplement canvien el fons; altres inverteixen o recoloren agressivament la vostra paleta, de vegades parcialment. El resultat és que un botó amb text fosc sobre un color de marca clar pot acabar amb text fosc sobre un fons fosc invertit, deixant el contrast a no res. El text negre dins d’una caixa de color pot tornar-se invisible. Els logotips amb fons transparents poden desaparèixer contra un llenç fosc.

No hi ha cap control universal sobre el mode fosc, i les tècniques que existeixen varien segons el client, però els principis defensius són estables. Dissenyeu tenint en compte els dos modes. Eviteu el negre pur o el blanc pur com a colors base, ja que no deixen marge perquè el client s’ajusti. Doneu als logotips i als gràfics clau un contorn contrastat o una placa de fons sòlida perquè sobrevisquin a la inversió. Proveu el resultat realment renderitzat en mode fosc a cada client principal en lloc de confiar que el vostre disseny de mode clar es traduirà. L’objectiu és que el text i els elements interactius es mantinguin per sobre del llindar de contrast independentment de com els giri el client.

Enllaços descriptius i botons accessibles

Els usuaris de lectors de pantalla sovint despleguen una llista de tots els enllaços d’un missatge per navegar o decidir on anar. En aquesta llista, el text de l’enllaç apareix despullat del seu context circumdant. Un missatge ple de «Feu clic aquí», «Llegiu més» i «Sapigueu-ne més» produeix un inventari inútil d’entrades idèntiques i sense sentit. El text de cada enllaç hauria de tenir sentit per si mateix: «Llegiu el nostre informe de sostenibilitat de primavera» o «Seguiu la vostra comanda» diu a l’usuari exactament on porta l’enllaç sense cap frase circumdant.

El mateix s’aplica als botons, que al correu solen ser enllaços amb estil per semblar botons — sovint construïts amb la tècnica del «botó a prova de bales» utilitzant taules imbricades i colors de fons perquè es renderitzin a tots els clients. Sigui quina sigui la construcció, el nom accessible del botó ha de descriure la seva acció. Un botó buit o vague, o un el text del qual només viu en una imatge de fons, és un carreró sense sortida per a la tecnologia d’assistència. Si el botó es basa en imatge, l’acció pertany al text alternatiu de la imatge.

Feu els objectius d’enllaços i botons prou grans per tocar-los còmodament — WCAG 2.2 va introduir una mida mínima d’objectiu, i al mòbil un objectiu tàctil massa petit frustra tothom, no només els usuaris amb discapacitats motrius. Assegureu-vos que els enllaços es distingeixin per més que només el color, ja que els enllaços només per color fallen per als usuaris amb baixa visió o daltonisme; un subratllat és la pista més segura. I doneu a cada enllaç una destinació real i funcional en lloc d’un marcador de posició. El text d’enllaç vague és una de les fallades més comunes que veiem, i apareix també al web, no només al correu — el nostre resum de problemes d’accessibilitat habituals a evitar cobreix el mateix patró en un context més ampli.

El preheader i l’experiència de previsualització

El preheader — de vegades anomenat text de previsualització — és el fragment de text que apareix al costat o sota la línia d’assumpte a la safata d’entrada, abans que s’obri el missatge. Molts correus el malgasten, deixant-lo recórrer al text que casualment ve primer: una línia «El correu no es mostra correctament?», un enllaç de «cancel·lació de subscripció» o una cadena de text alternatiu buit. Per als usuaris de lectors de pantalla que naveguen per la seva safata d’entrada, i per a tothom que decideix si obrir-lo, aquest preheader malgastat és una oportunitat perduda per comunicar.

Escriviu un preheader deliberat i significatiu que resumeixi el propòsit del correu, i col·loqueu-lo com el primer contingut de text al cos perquè sigui el que la safata d’entrada capta. La tècnica estàndard és un bloc de text ocult prop de la part superior del correu, amb estil per ser visualment ocult però encara disponible per als clients i la tecnologia d’assistència. Aneu amb compte amb com l’amagueu: un preheader mal amagat pot aparèixer com una línia visible no desitjada o ser omès completament pels lectors de pantalla. Encoixineu-lo adequadament perquè el contingut posterior de la safata d’entrada no filtri text adjacent a la previsualització.

Tracteu el preheader com a part de l’arquitectura d’informació del missatge. Combinat amb una línia d’assumpte clara i un encapçalament d’obertura fort, dóna a cada destinatari — vident o no — una sensació ràpida i precisa de què és el correu i per què importa.

Disseny responsiu i zoom

Els correus es llegeixen als telèfons tant com als ordinadors, i els llegeixen persones que fan zoom per ampliar el text. Tots dos exigeixen que el disseny s’adapti. Un disseny fix i ample que força el desplaçament horitzontal en una pantalla petita, o que es trenca quan un usuari augmenta la mida del text, és una barrera — i WCAG 2.2 té criteris tant per al reflux com per a l’espaiat del text que s’apliquen aquí.

Construïu els correus perquè siguin responsius: un disseny d’una sola columna a les pantalles estretes és gairebé sempre l’elecció més robusta i accessible, perquè preserva l’ordre de lectura i evita el contingut costat a costat que col·lapsa de manera imprevisible. On utilitzeu consultes de mitjans per canviar dissenys, recordeu que alguns clients les ignoren, de manera que la renderització per defecte ha de seguir sent usable. Establiu mides de tipus de lletra prou grans per llegir sense fer zoom — el text de cos per sota d’aproximadament 14 a 16 píxels és difícil per a moltes persones al mòbil — i eviteu fixar l’alçada de línia o l’espaiat de lletres tan estretament que el text ampliat se superposi o es talli.

Proveu què passa quan un usuari fa zoom o augmenta la mida de la lletra del sistema del seu dispositiu. El contingut hauria de refluir i seguir sent llegible en lloc de desbordar el seu contenidor o desaparèixer darrere d’altres elements. La recompensa és un correu que funciona no només per als usuaris amb baixa visió sinó per a tothom que llegeix en una pantalla petita en condicions imperfectes.

Proves a través de clients i lectors de pantalla

No podeu verificar l’accessibilitat del correu inspeccionant només el codi, perquè tot el repte és que els clients renderitzen el mateix codi de manera diferent. Les proves s’han de fer a través d’una matriu representativa de clients i tecnologies d’assistència, en les condicions que utilitzen els destinataris reals.

Cobriu com a mínim els clients principals: Outlook (escriptori a Windows, més les versions web i noves), Gmail (web i l’aplicació mòbil) i Apple Mail (macOS i iOS). Per a cadascun, comproveu la renderització tant en mode clar com fosc, amb les imatges activades i desactivades, i amb zoom augmentat. Després superposeu-hi lectors de pantalla — VoiceOver amb Apple Mail a macOS i iOS, NVDA o JAWS amb Outlook i Gmail a Windows, i TalkBack amb l’aplicació Gmail a Android. Escolteu el correu de la manera com ho faria un usuari de lector de pantalla: s’anuncien els encapçalaments, és lògic l’ordre de lectura, estan silencioses les taules de disseny, tenen sentit els enllaços a la llista d’enllaços, anuncien les imatges text alternatiu útil o es queden en silenci quan són decoratives?

Les comprovacions automatitzades tenen el seu lloc — poden senyalar ràpidament atributs alt absents, baix contrast i atributs d’idioma absents a través de moltes plantilles — però no poden jutjar si el text alternatiu és significatiu, si l’ordre de lectura explica la història correcta, o si el nom d’un botó descriu la seva acció. Aquest judici requereix proves manuals, idealment incloent proves per part de persones que utilitzen tecnologia d’assistència cada dia. La nostra guia d’auditories manuals d’accessibilitat explica per què les proves humanes són insubstituïbles, i les nostres auditories per part de persones amb discapacitat aporten exactament aquesta perspectiva d’experiència viscuda al correu.

Una advertència: no us deixeu temptar pels widgets de «superposició» d’accessibilitat que prometen compliment instantani. No funcionen per als llocs web, i són irrellevants per al correu, on no hi ha cap pàgina on injectar un script. L’accessibilitat real del correu prové de corregir el marcatge, no d’un afegit.

Reparació de plantilles a nivell d’ESP

Corregir un correu és útil. Corregir la font que genera cada correu és transformador. La majoria d’organitzacions envien a través d’un proveïdor de serveis de correu electrònic — Mailchimp, Klaviyo, Salesforce Marketing Cloud, Braze i similars — on les campanyes s’assemblen a partir de plantilles mestres, mòduls reutilitzables i blocs de contingut d’arrossegar i deixar anar. Si aquestes plantilles subjacents porten les correccions d’accessibilitat, cada enviament futur les hereta automàticament, i l’equip de màrqueting no ha de recordar una llista de comprovació per a cada campanya.

Aquest és el lloc més rendible per invertir. Repareu la plantilla mestra perquè les taules de disseny portin role="presentation", l’atribut d’idioma estigui establert, l’estructura del preheader estigui al seu lloc i la bastida d’encapçalaments sigui correcta. Repareu cada mòdul reutilitzable — el bloc hero, la targeta d’article, el botó, el peu — perquè tot el que l’equip hi arrossegui sigui accessible per construcció. Establiu patrons per al text alternatiu perquè els editors siguin incitats a escriure’l, i incorporeu colors segurs per al contrast i conscients del mode fosc a la paleta de marca que utilitzen les plantilles.

El parany és que els constructors d’arrossegar i deixar anar també poden fer regressar l’accessibilitat: un constructor pot eliminar role="presentation", malmetre el marcatge en exportar, o deixar que un editor enganxi un bloc inaccessible. Així que la reparació de plantilles s’ha d’aparellar amb governança — directrius, passos de revisió i reproves periòdiques a mesura que l’ESP i el seu comportament d’exportació canvien. Aquí és on val la pena integrar l’accessibilitat al flux de treball; el nostre servei de millora del procés d’accessibilitat ajuda els equips a fer del correu accessible la norma en lloc d’una idea secundària, i la consultoria d’accessibilitat l’alinea amb el vostre programa de compliment més ampli. Per a les organitzacions sota la European Accessibility Act, les comunicacions accessibles amb els clients formen part del panorama, cosa que exposa la nostra visió general de compliment de l’EAA.

QualiBooth combina programari d’escaneig d’accessibilitat per als problemes que les màquines detecten de manera fiable amb reparació manual experta per als judicis que no poden fer — a través de llocs web, documents i correu per igual. Si els vostres correus formen part de com serviu els clients, mereixen el mateix rigor que la resta del vostre patrimoni digital.

Conclusió

L’accessibilitat del correu electrònic no és una versió més petita de l’accessibilitat web — és una disciplina relacionada però diferent, modelada per un panorama de clients fragmentat, dissenys basats en taules i motors de renderització que ignoren gran part del web modern. La bona notícia és que les tècniques estan ben establertes: estructura semàntica i un esquema d’encapçalaments sòlid, role="presentation" a cada taula de disseny, text alternatiu significatiu amb alt buit per a la decoració, contrast que sobreviu al mode fosc, enllaços i botons que es descriuen ells mateixos, un preheader deliberat, dissenys responsius que resisteixen el zoom, i proves disciplinades a través de clients i lectors de pantalla. Apliqueu-les a nivell de plantilla i l’accessibilitat deixa de ser una tasca per campanya i es converteix en una propietat del vostre sistema.

La recompensa és real. Els correus accessibles arriben a més persones, es llegeixen clarament amb les imatges desactivades, i tendeixen a rendir millor perquè la claredat i la robustesa ajuden tothom. Si voleu ajuda, el nostre servei de reparació de correu electrònic pot auditar les vostres plantilles, corregir-les a nivell d’ESP i verificar el resultat a tota la matriu de clients — i podeu sol·licitar una demostració o executar un escaneig gratuït del vostre lloc web per veure on es troba la resta del vostre patrimoni digital.

Preguntes freqüents

Necessito realment role="presentation" a cada taula de disseny? Sí. Sense això, els lectors de pantalla anuncien cada taula de disseny com a taula de dades, llegint els recomptes de files i columnes i interrompent el flux. Com que els dissenys de correu imbriquen taules, l’atribut ha d’estar a cada taula de disseny, no només al contenidor extern. Les taules de dades genuïnes, com els rebuts, mantenen la seva semàntica de dades en canvi.

Què he de posar al text alternatiu d’una imatge decorativa? Utilitzeu un atribut alt buit, escrit alt="", perquè els lectors de pantalla ometin la imatge. No ometeu l’atribut completament, perquè un alt absent sovint fa que el nom de fitxer o l’URL de la imatge es llegeixi en veu alta.

Com evito que el mode fosc trenqui el meu correu? No podeu controlar completament com cada client gestiona el mode fosc, però podeu dissenyar defensivament: eviteu el negre i el blanc purs, doneu als logotips un fons o contorn contrastat, mantingueu el contrast per sobre dels llindars de WCAG 2.2, i proveu el resultat renderitzat en mode fosc a cada client principal en lloc de suposar que el vostre disseny de mode clar es traslladarà.

Pot una eina automatitzada fer el meu correu accessible? Les eines automatitzades detecten alguns problemes — atributs alt absents, baix contrast, configuracions d’idioma absents — però no poden jutjar si el text alternatiu és significatiu, si l’ordre de lectura té sentit, o si els enllaços i botons descriuen el seu propòsit. Això requereix proves manuals amb lectors de pantalla. Els widgets de superposició d’accessibilitat no són una solució i no s’apliquen al correu.

És millor corregir correus individuals o plantilles? Plantilles. Reparar plantilles mestres i mòduls reutilitzables al vostre ESP significa que cada enviament futur hereta les correccions, cosa que és molt més rendible que corregir campanyes una per una. Apareu-ho amb governança perquè els constructors d’arrossegar i deixar anar no reintrodueixin problemes.