La accesibilidad solía ser el último punto de la checklist del email, eso que hacías si sobraba tiempo. Se acabó. Desde el 28 de junio de 2025 la Ley Europea de Accesibilidad está en vigor, y las mismas correcciones de texto alt y de contraste que ayudan a quien usa un lector de pantalla deciden también si tu mensaje sobrevive con las imágenes desactivadas o hace saltar un filtro de spam. La accesibilidad es ahora un problema de alcance, un problema legal y un problema de entregabilidad a la vez.
Así que empecemos por lo que medimos de verdad. Entre los emails que pasan por Unspam, el 84% supera sus comprobaciones de accesibilidad, una cifra que suena saludable hasta que ves dónde se concentran los fallos: atributos de idioma ausentes, tablas de maquetación sin marcar, contraste bajo y falta de texto alt. Esa es la distancia que cierra esta guía. Está escrita para las dos mitades de la sala, la del marketer que necesita el qué y el porqué, y la del desarrollador que necesita el cómo, con código real listo para copiar donde hace falta.
¿Qué es la accesibilidad del email?
La accesibilidad del email consiste en crear un email que todo el mundo pueda percibir, manejar y entender, incluidas las personas que usan un lector de pantalla, navegan con el teclado, amplían el texto, leen en modo oscuro o tienen baja visión o daltonismo. En la práctica son los principios de WCAG 2.2 (perceptible, operable, comprensible, robusto) aplicados a las limitaciones de la bandeja de entrada: texto real en vez de imágenes con el texto incrustado, textos alt descriptivos, contraste de color suficiente, estructura semántica y un idioma declarado.
A diferencia de la accesibilidad web, la del email sortea las limitaciones de la bandeja de entrada: nada de CSS externo, maquetación con tablas y clientes de correo que bloquean las imágenes por defecto. Los principios son los mismos, pero las tácticas las moldea el sitio donde aterriza el mensaje.
Buenas prácticas de accesibilidad del email de un vistazo
Estas son las prácticas centrales, en el orden en que la mayoría de los emails las incumple. Cada una se desarrolla más abajo con su cómo.
- Dale a cada imagen informativa un texto
altdescriptivo, y a las decorativas unalt=""vacío - Estructura el mensaje con encabezados reales de
<h1>a<h6>, no con texto en negrita - Añade
role="presentation"a todas las tablas de maquetación para que los lectores de pantalla lean el contenido de forma lineal - Cumple el contraste de color: 4,5:1 para el texto normal, 3:1 para el texto grande y los elementos de interfaz
- Diseña pensando en el modo oscuro y comprueba el contraste en ambos modos
- Escribe textos de enlace que describan su destino, nunca "haz clic aquí"
- Mantén áreas táctiles cómodas y el texto del cuerpo entre 14 y 16px
- Declara el idioma con
<html lang="en">y envía una parte de texto plano real
Qué vemos en los emails que analizamos
La mayoría de las guías de accesibilidad argumentan a partir de estadísticas de público: cuánta gente tiene una discapacidad. Es un dato real, y lo cubrimos más abajo, pero no es evidencia sobre tu email. Las cifras de esta sección sí lo son, porque salen de los emails que pasan de verdad por Unspam.
- El 84% de los emails que comprobamos supera sus comprobaciones de accesibilidad. Es mucho más optimista que la cifra de todo o nada del "99,88% de los emails falla" que quizá hayas visto citada, y resulta más útil: una puntuación graduada te dice que la mayoría de los emails ya ha recorrido casi todo el camino, y que la distancia restante es pequeña y salvable.
- Cuando un email sí falla, los fallos se concentran en unos pocos puntos predecibles: un atributo
langausente, tablas de maquetación sin marcar, contraste bajo y falta de texto alt. - Nuestra comprobación de accesibilidad señala en concreto el texto que resulta invisible o ilegible para las personas por los colores de texto y de fondo que usa, es decir, el contraste de color bajo. Todo su propósito es darte una visión general de dónde estás y de qué corregir.
Ayuda leer ese 84% junto al resto de lo que medimos. Las señales de contenido son sistemáticamente el eslabón más débil: solo el 30% de los emails supera nuestras comprobaciones de buenas prácticas de HTML, la tasa de aprobado más baja de todo lo que analizamos. La accesibilidad, con su 84%, está en mucha mejor forma que el HTML que hay debajo de tu email, lo que te dice que las victorias son concretas y localizadas, no una reconstrucción entera.
Un atributo alt vacío es una decisión. Uno ausente es un accidente que lee tu nombre de archivo en voz alta.
Por qué importa la accesibilidad del email
El público es más grande de lo que crees
El argumento del alcance es sencillo. En Estados Unidos, más de uno de cada cuatro adultos, el 28,7% o más de 70 millones de personas, declaró tener una discapacidad en 2022 (CDC, a partir de la encuesta BRFSS de 2022), y un 5,5% declaró una discapacidad visual en concreto. En todo el mundo, la Organización Mundial de la Salud estima que al menos 2.200 millones de personas tienen algún tipo de deficiencia visual de cerca o de lejos. Solo el daltonismo afecta aproximadamente a 1 de cada 12 hombres y a 1 de cada 200 mujeres de ascendencia del norte de Europa (Colour Blind Awareness). Y buena parte del correo se abre en el móvil, donde el texto pequeño y las áreas táctiles diminutas le fallan a todo el mundo, no solo a quien tiene una discapacidad diagnosticada.
No hace falta que todas estas personas sean ciegas para que el trabajo salga a cuenta. Un titular con poco contraste también es difícil de leer en un teléfono a pleno sol para alguien con visión perfecta.
El panorama legal
La ley de accesibilidad es ya lo bastante real como para que el "no lo sabíamos" no sirva de defensa. Hay tres regímenes que importan sobre todo a quien envía correo, y no coinciden en los detalles.
| Régimen | A quién cubre | Estándar | En vigor |
|---|---|---|---|
| Ley Europea de Accesibilidad (Directiva (UE) 2019/882) | Empresas, también de fuera de la UE, que venden productos y servicios cubiertos en la UE, con el comercio electrónico y las comunicaciones electrónicas incluidos | EN 301 549, que incorpora WCAG | Las obligaciones se aplican desde el 28 de junio de 2025 |
| Título III de la ADA (EE. UU.) | Espacios de acceso público en EE. UU.; los tribunales tratan las webs y apps de empresa como cubiertas | Sin estándar WCAG codificado; WCAG 2.1 AA es la referencia de facto en los acuerdos | ADA desde 1990, la postura sobre la web sigue en construcción |
| Título II de la ADA (EE. UU.) | Webs y apps de administraciones estatales y locales de EE. UU. | WCAG 2.1 AA (norma del DOJ de 2024) | Plazos ampliados: 26 de abril de 2027 (población de 50.000+), 26 de abril de 2028 (menores) |
| Sección 508 (EE. UU.) | Agencias federales de EE. UU. y sus proveedores | WCAG 2.0 AA, una versión por detrás del Título II | Obligatoria desde el 18 de enero de 2018 |
Unas cuantas advertencias honestas. La Ley Europea de Accesibilidad no nombra el "email marketing" como categoría; su alcance sobre el correo es indirecto pero real, más fuerte en los mensajes transaccionales y de servicio ligados a un comercio electrónico o un servicio bancario cubierto, y más gris en el correo puramente promocional, donde el trato depende de la transposición nacional. El Título III de la ADA no fija una regla WCAG para la empresa privada; WCAG 2.1 AA es lo que usan los tribunales y los acuerdos, no una ley. No existe ninguna certificación que haga que un email sea formalmente conforme a la ADA; lo que la expresión significa en la práctica es la conformidad con WCAG 2.1 o 2.2 AA. Y los plazos del Título II para las administraciones estadounidenses se ampliaron un año en abril de 2026, así que las fechas actuales son 2027 y 2028, no 2026 y 2027. La lectura segura de todo esto: construye según WCAG 2.2 AA y cumplirás el listón allá donde exista uno.
El argumento de negocio
La accesibilidad no es una obra de caridad que te cuesta dinero. Se solapa casi por completo con el trabajo que mejora la visualización y la entregabilidad:
- Resistencia con las imágenes desactivadas. Muchos clientes de correo bloquean las imágenes por defecto. El texto alt descriptivo se convierte en tu texto de reserva, así que el mensaje sobrevive intacto tanto si quien lee es ciego como si simplemente tiene las imágenes desactivadas.
- Puntuación de spam. Los filtros desconfían del correo hecho solo de imágenes. El texto real y en vivo mejora la proporción entre texto e imagen, lo que ayuda a la vez a quien usa un lector de pantalla y a tu llegada a la bandeja de entrada.
- Una parte de texto plano de verdad. Un mensaje
multipart/alternativeauténtico con una partetext/plainen condiciones sirve a los clientes de correo de solo texto y a los de tecnología asistiva, y mejora la llegada a la bandeja de entrada. Una sola corrección, dos victorias. - Interacción. Un tamaño de fuente legible y un contraste fuerte mejoran la lectura para todo el mundo, lo que eleva las señales de interacción que premian los proveedores de correo. Un mapa de calor del email te enseña si quien lee llega de verdad a tu CTA una vez que el texto es legible.
WCAG para email: qué criterios se aplican de verdad
La mayoría de las guías sueltan WCAG A/AA/AAA y siguen adelante. Aquí tienes el mapeo concreto, criterio por criterio, y cómo se satisface cada uno en un email.
| Criterio de WCAG 2.2 | Nivel | Qué significa en el email | Cómo cumplirlo |
|---|---|---|---|
| 1.1.1 Contenido no textual | A | Las imágenes necesitan alternativas textuales | alt descriptivo en las imágenes informativas, alt="" en las decorativas |
| 1.3.1 Información y relaciones | A | La estructura debe ser programática, no solo visual | Encabezados reales de <h1> a <h6>, role="presentation" en las tablas de maquetación |
| 1.4.3 Contraste (mínimo) | AA | El texto debe leerse sobre su fondo | 4,5:1 en texto normal, 3:1 en texto grande |
| 1.4.11 Contraste no textual | AA | Los objetos de interfaz y gráficos deben distinguirse | 3:1 en botones, iconos y estados de foco |
| 2.4.4 Propósito de los enlaces | A | El texto del enlace debe tener sentido fuera de contexto | Describe el destino, nada de "haz clic aquí" |
| 2.5.8 Tamaño del objetivo (mínimo) | AA | Los objetivos interactivos deben ser lo bastante grandes para acertarlos | 24 x 24 px CSS como mínimo, o la excepción por espaciado |
| 3.1.1 Idioma de la página | A | El software de quien lee debe conocer el idioma | <html lang="en">, lang en línea en los fragmentos en otro idioma |
Dos de ellos, el contraste y el tamaño del objetivo, se detallan en la sección de diseño de más abajo, porque son los que la gente cita mal.
Cómo hacer accesible un email: contenido y estructura
Encabezados reales, no texto maquillado
Quien usa un lector de pantalla navega por los contenidos largos saltando de encabezado en encabezado. Eso solo funciona si tus encabezados son elementos de encabezado de verdad.
- Usa
<h1>a<h6>para la jerarquía, no un<span>en negrita ni un<td>grande que simplemente parezca un encabezado. - Usa un único
<h1>lógico y anida hacia abajo sin saltarte niveles. Un<h2>seguido de un<h4>rompe el modelo de lectura por encabezados y es una de las cosas que marcamos. - Mantén el orden del código fuente (DOM) igual al orden de lectura. Los lectores de pantalla y la visualización móvil linealizada siguen el orden del código, no la posición visual del CSS, así que no confíes nunca en el CSS para reordenar el significado.
Enlaces descriptivos, nunca "haz clic aquí"
Un lector de pantalla puede sacar una lista con todos los enlaces del mensaje, leídos fuera de contexto. "Haz clic aquí" cinco veces no sirve de nada en esa lista.
- Escribe textos de enlace que nombren el destino: "lee la checklist de entregabilidad", no "leer más".
- Evita las URL en crudo como texto de enlace; se leen carácter a carácter.
- Deja las palabras con significado dentro del enlace, no alrededor.
Diseño de emails accesibles
Contraste de color y tamaño del objetivo
El contraste es el criterio en el que se centra la propia comprobación de Unspam, que señala el texto que resulta invisible sobre su fondo. Los umbrales son exactos, y son umbrales, no objetivos que redondees al alza: 4,499:1 no supera el 4,5:1.
| Contenido | Mínimo WCAG AA | WCAG AAA |
|---|---|---|
| Texto normal (menos de 18pt / menos de 14pt en negrita) | 4,5:1 | 7:1 |
| Texto grande (18pt regular / 14pt en negrita y más) | 3:1 | 4,5:1 |
| Componentes de interfaz y objetos gráficos | 3:1 | n/d |
El "texto grande" tiene una definición exacta compartida por estos criterios: 18pt en regular (unos 24px) o 14pt en negrita (unos 18,66px). Todo lo que sea más pequeño cuenta como texto normal y debe cumplir el 4,5:1 completo.
El tamaño del objetivo es el dato que todo el mundo cita mal. El mínimo AA de WCAG 2.2 (SC 2.5.8) es de 24 x 24 px CSS, con una excepción por espaciado para los objetivos más pequeños que no estén rodeados de otros objetivos. La famosa cifra de 44 x 44 es más estricta: es WCAG AAA (SC 2.5.5) y el mínimo de las Human Interface Guidelines de Apple, no el requisito AA. Así que "WCAG exige 44 x 44" es un error habitual. Trata 24 x 24 como conforme y 44 x 44 como cómodamente usable, y apunta a este último en cualquier CTA principal.
- No transmitas nunca el significado solo con el color. Acompaña un estado de error en color con un icono o una etiqueta, y subraya los enlaces para que el daltonismo no los esconda.
- Dales a los botones un tamaño real y pulsable, con un padding generoso, sobre todo en el móvil.
Tipografía y maquetación
- Pon el texto del cuerpo entre 14 y 16px, con 16px como preferencia para el móvil, y usa tamaños mayores en los encabezados.
- Usa una maquetación responsive de una sola columna que se reajuste con limpieza al ampliar y en pantallas estrechas. La misma disciplina aparece en todo el trabajo actual de diseño de emails.
- Mantén las líneas aproximadamente de 45 a 75 caracteres, algo que una maquetación de una sola columna de 600px a 16px consigue de forma natural, y fija una altura de línea alrededor de 1,5. Declara fuentes de respaldo para que una fuente web no compatible degrade a algo legible.
Texto alt bien hecho
La falta de texto alt es uno de los fallos que marca nuestra comprobación, y la solución es precisa, no un simple "pon alt en todas partes".
- Imágenes informativas: describe la función o el contenido, no el medio. Escribe
alt="Spring sale, 30% off all boots", noalt="banner image", y nuncaalt="image of...". - Imágenes decorativas: dales un
alt=""vacío y explícito (alt nulo) para que los lectores de pantalla las salten por completo. Hablamos de un espaciador, un separador, un adorno de fondo. - No omitas el
altpor completo. Un atributo ausente no es lo mismo que uno vacío; algunos lectores responden anunciando el nombre del archivo o la URL en voz alta, que es justo el accidente que describía la cita destacada de arriba. - Recuerda que el texto alt es también tu contenido para cuando las imágenes están desactivadas, así que escríbelo de forma que el mensaje se mantenga intacto cuando la imagen no llegue a cargarse.
La otra cara del texto alt es no necesitarlo de entrada. La forma más rápida de suspender todas las comprobaciones a la vez es el email hecho solo de imágenes: un titular incrustado en un JPEG no lo puede leer un lector de pantalla, no se reajusta al ampliar, no se adapta al modo oscuro y desaparece por completo con las imágenes desactivadas. Mantén los titulares, el texto del cuerpo y los botones como texto HTML en vivo, y reserva las imágenes para lo que solo una imagen puede mostrar.
Animación y GIF
La animación tiene reglas estrictas. Mantén cualquier GIF por debajo de tres destellos por segundo, detenlo después de unos tres bucles o cinco segundos y pon el mensaje completo en el primer fotograma, porque las versiones antiguas de Outlook solo muestran el fotograma uno. En los clientes de correo que lo admiten, prefers-reduced-motion te permite sustituirlo por una imagen estática para quien le ha pedido a su dispositivo menos movimiento.
Código de emails accesibles
Esta es la mitad para desarrolladores. Todo está listo para copiar.
role="presentation" en las tablas de maquetación
El email sigue usando tablas para maquetar. Sin marcar, un lector de pantalla anuncia cada fila, columna y celda como si fueran datos, y eso es ruido. Marca todas las tablas de maquetación para que se lean de forma lineal:
<table role="presentation" cellpadding="0" cellspacing="0" border="0" width="100%">
<tr>
<td>Your actual content, read in source order.</td>
</tr>
</table>
role="none" es un sinónimo, pero role="presentation" tiene el soporte más amplio en tecnología asistiva, así que es preferible. Aplícalo a todas las tablas de maquetación, incluidas las anidadas.
lang (y dir) para que la voz sea la correcta
Los lectores de pantalla eligen su pronunciación y su perfil de voz a partir del idioma declarado del documento. Sin lang, el lector recurre a su idioma por defecto del sistema y lo pronuncia todo mal: un texto en francés leído con fonética inglesa, por ejemplo. La falta de lang es uno de los defectos más habituales del mundo real en todo el correo, y cuesta una línea arreglarlo:
<html lang="en" dir="ltr">
Para un alfabeto de derecha a izquierda, pon dir="rtl". Para contenido en varios idiomas, sobrescríbelo por fragmento con un atributo en línea: <span lang="fr">merci beaucoup</span>.
CTA a prueba de balas y accesibles
Construye los botones como enlaces reales con estilo de botón, dimensionados para el dedo y con texto descriptivo dentro del ancla:
<a href="https://example.com/checklist"
style="display:inline-block; padding:14px 28px; font-size:16px;
background:#1a4d8f; color:#ffffff; text-decoration:none;
border-radius:6px;">
Read the deliverability checklist
</a>
El texto del enlace transmite el significado por sí solo, el padding le da un objetivo cómodo y la combinación de colores supera el 4,5:1.
Modo oscuro y accesibilidad
El modo oscuro no es un solo comportamiento, son tres, y cada uno puede romper el contraste a su manera: inversión total (fondo y texto ambos invertidos), inversión parcial (texto invertido, fondos mayormente intactos) y ningún cambio. El caso parcial es el peligroso, porque las paletas invertidas a medias producen combinaciones turbias y de bajo contraste que nunca diseñaste.
Declara tu intención para que la inversión automática agresiva se eche atrás:
<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">
Después combínalo con el color-scheme correspondiente en CSS sobre tu body. Dos rarezas de clientes de correo que conviene sortear con código:
- Apple Mail invierte el
#000000puro y el#FFFFFFpuro. La solución es un casi negro y un casi blanco,#000001y#FFFFFE, visualmente idénticos pero exentos de la inversión forzada. - Outlook de escritorio (Microsoft 365 en Windows) hace inversión total, el modo más invasivo, y recolorea incluso los diseños oscuros. Outlook.com en la web hace inversión parcial, detecta los fondos claros y les da la vuelta, y añade los atributos
data-ogscydata-ogsba tus elementos cuando reescribe colores, que es lo que hace posible apuntar al modo oscuro con[data-ogsc].
La regla que sobrevive a todo esto: el contraste sigue aplicándose en modo oscuro. Previsualiza tu email en modo oscuro en clientes de correo reales y comprueba ambos modos frente al 4,5:1 y al 3:1. Los logotipos y los iconos sobre fondos transparentes son el fallo clásico del modo oscuro, invisibles en cuanto el fondo se invierte debajo de ellos.
Cómo tratan los lectores de pantalla a Gmail, Outlook y Apple Mail
El mismo email accesible se anuncia y se muestra de forma distinta según el cliente de correo y el lector de pantalla. Eso condiciona qué optimizas.
| Cliente de correo y lector | Qué anuncia la fila de la bandeja | Dentro del mensaje abierto |
|---|---|---|
| Apple Mail + VoiceOver | Remitente, asunto, hora de recepción | Control-Opción-J lee el cuerpo del mensaje |
| Outlook + VoiceOver (Mac) | Remitente, asunto, fecha, si hay adjuntos | Las flechas izquierda y derecha recorren el contenido del mensaje |
| Gmail (modo lector de pantalla) | Se mueve entre conversaciones con j/k o las flechas; Intro u o abre | n lee cada mensaje sin leer, del más antiguo al más reciente |
La implicación es práctica: el asunto y el preheader cargan con mucho peso porque se anuncian antes de que el cuerpo llegue a abrirse. Una vez dentro, tus encabezados y tus tablas con role="presentation" deciden lo navegable que resulta el cuerpo.
De ahí se derivan dos detalles. Si usas el truco del preheader oculto, los caracteres de relleno invisibles que mantienen el texto del cuerpo fuera de la vista previa de la bandeja no son invisibles para un lector de pantalla; envuelve el span de relleno en aria-hidden="true" para que la tecnología asistiva lo salte en vez de leer un muro de nada. Y un lector de pantalla anuncia cada emoji por su nombre completo, así que un asunto que arranca con dos emojis de fiesta se oye como ruido antes de que llegue tu oferta. Usa los emojis con moderación, ponlos al final del asunto o de la frase y no dejes nunca que uno sustituya a una palabra que el mensaje necesita.
Cómo probar la accesibilidad de un email
Las pruebas son donde la mayoría de las guías se despacha con una lista de herramientas. Aquí tienes la versión a fondo.
Pasa primero una comprobación automática
Empieza por la pasada rápida y repetible. La comprobación de accesibilidad de Unspam se ejecuta dentro del test de spam gratuito de la página de inicio, modela tu email frente a WCAG 2.2 AA y analiza siete cosas a la vez: contraste de color (objetivo 4,5:1), texto alt de las imágenes, comportamiento en modo oscuro, orden de los encabezados sin saltarse niveles, texto descriptivo en los enlaces, tamaño de las áreas táctiles y un atributo lang declarado. Te da una visión graduada de dónde estás y de qué mejorar, en vez de un único veredicto de apto o no apto.
Combínala con las comprobaciones de contenido relacionadas que se solapan con la accesibilidad: el comprobador de palabras spam para el texto que perjudica tanto a la lectura como a la llegada a la bandeja de entrada, y el verificador de correo para mantener limpia la propia lista y que tu correo accesible llegue de verdad a gente interesada.
Después prueba con un lector de pantalla real
Las puntuaciones automáticas detectan los fallos mecánicos. No pueden decirte si tu texto alt tiene sentido leído en voz alta. Para eso hay que probar a mano, idealmente con los lectores gratuitos que vienen integrados en las plataformas que usa tu público:
- Envíate el email y ábrelo en el cliente de correo objetivo.
- Activa el lector de pantalla (VoiceOver en Apple, NVDA en Windows, TalkBack en Android).
- Escucha el orden de lectura. ¿Tiene sentido el mensaje de forma lineal? ¿Se anuncian los encabezados como encabezados?
- Comprueba que las imágenes decorativas se saltan y que las informativas leen una descripción útil.
- Confirma que los enlaces anuncian su destino fuera de contexto.
Comprobaciones de teclado y zoom
- Recorre el mensaje con el tabulador. Cada elemento interactivo debería ser alcanzable y tener un estado de foco visible.
- Amplía al 200%. El texto debería reajustarse dentro de la columna única sin recortes ni desplazamiento horizontal.
- Mira el email con las imágenes desactivadas y confirma que el texto alt transmite el mensaje por sí solo.
Qué corregir primero
Si solo tienes una hora, dedícala en este orden. Esta clasificación combina nuestros propios datos con el ranking de frecuencia de problemas del informe de accesibilidad de 2026 del Email Markup Consortium, que concluye que la falta de dir y la falta de lang son los defectos más habituales del mundo real, por delante de las tablas de maquetación sin rol, el contraste bajo y la falta de texto alt.
- Añade el atributo
lang(ydir). Una línea, ausente casi en todas partes, victoria inmediata para cualquiera que use un lector de pantalla. - Marca todas las tablas de maquetación con
role="presentation". Convierte un muro de ruido de tablas en contenido lineal. - Corrige el texto alt que falta. Un atributo
altausente descarta la imagen en silencio; un alt descriptivo además te protege con las imágenes desactivadas. - Repara el contraste de color bajo. Es la comprobación que Unspam señala de forma directa, y la que también les falla a los usuarios de móvil que ven perfectamente.
- Sustituye el texto maquillado por encabezados reales. Desbloquea la navegación por encabezados.
- Reescribe los enlaces con un "haz clic aquí" pelado. Es barato y hace que tu lista de enlaces sea utilizable.
La checklist de accesibilidad del email (cópiala)
- Cada imagen informativa tiene un texto
altdescriptivo; las decorativas tienenalt="" - Encabezados reales de
<h1>a<h6>en orden, sin saltarse niveles -
role="presentation"en todas las tablas de maquetación - Contraste del texto de al menos 4,5:1 (3:1 en texto grande y elementos de interfaz)
- El significado no se transmite nunca solo con el color
- El texto del enlace describe su destino, nada de "haz clic aquí"
- Texto del cuerpo entre 14 y 16px, áreas táctiles cómodas en los CTA
-
<html lang="...">declarado,dirpuesto para los alfabetos de derecha a izquierda - Meta
color-schemepuesta y ambos modos comprobados en cuanto a contraste - Una parte
text/plainauténtica dentro de un mensajemultipart/alternative - Probado con un lector de pantalla real, con teclado, con zoom y con las imágenes desactivadas
La accesibilidad no es una gran reconstrucción, es este puñado de hábitos aplicados antes de cada envío, y la mayoría de ellos ayudan a la vez a tu entregabilidad. ¿Quieres saber dónde está tu próxima campaña? Pasa un test de spam gratuito y lee tu puntuación de accesibilidad en unos 30 segundos, sin registro.
