Guía de accesibilidad del correo HTML

Para la mayoría de las organizaciones, el correo electrónico es el punto de contacto más frecuente que tienen con sus clientes. Una confirmación de pedido, un restablecimiento de contraseña, un extracto mensual, un boletín: estos mensajes suelen llegar mucho antes de que alguien visite tu sitio web, y llegan con mucha más frecuencia. Sin embargo, la accesibilidad del correo electrónico es uno de los rincones más olvidados de la inclusión digital. Los equipos que invierten mucho en un sitio web accesible envían rutinariamente campañas construidas sobre marcado enredado, contenido solo de imágenes y botones que un lector de pantalla lee como «haz clic aquí».

La razón es en parte histórica y en parte técnica: el correo HTML es una disciplina propia, con sus propias limitaciones, sus propios motores de renderizado y sus propios modos de fallo. Técnicas que son naturales en la web moderna —puntos de referencia semánticos, diseños flexbox, propiedades personalizadas de CSS— son poco fiables o directamente inservibles en la matriz de clientes de correo. Hacer accesible un correo no es el mismo trabajo que hacer accesible una página web, y tratarlos como idénticos es precisamente la razón por la que tantos correos fracasan.

Esta guía recorre lo que la accesibilidad del correo realmente requiere: cómo estructurar el marcado para que la tecnología de asistencia pueda analizarlo, cómo manejar las tablas de presentación que aún sustentan el diseño del correo, cómo escribir texto alternativo y enlaces que tengan sentido fuera de contexto, cómo sobrevivir al modo oscuro y al zoom, y cómo probar el resultado en Outlook, Gmail, Apple Mail y lectores de pantalla. Si prefieres que especialistas hagan esto en tus plantillas, nuestro servicio de remediación de correo cubre toda la pila.

Por qué el correo HTML es una disciplina propia

Una página web se renderiza en un navegador. Hay un puñado de navegadores convencionales, se actualizan en calendarios predecibles y convergen en los estándares web. El correo es lo opuesto. Tu mensaje puede abrirse en docenas de clientes —Outlook en Windows, Outlook en la web, el nuevo Outlook, Gmail en un navegador, la app de Gmail, Apple Mail en macOS y iOS, Yahoo, Samsung Email y muchos más—, cada uno con un motor de renderizado distinto y un subconjunto diferente, a menudo cada vez menor, de HTML y CSS compatibles.

El ejemplo más conocido es Outlook de escritorio en Windows, que históricamente renderizaba el correo usando el motor de Microsoft Word en lugar de un motor de navegador real. Eso por sí solo obliga a los desarrolladores de correo a volver a los diseños basados en tablas, los estilos en línea y los patrones defensivos que la web abandonó hace años. Muchos clientes además eliminan los bloques <style>, rechazan el CSS moderno y reescriben atributos que consideran inseguros.

Para la accesibilidad, esto importa enormemente. El HTML semántico en el que confías para un sitio web —<nav>, <main>, los puntos de referencia ARIA— se elimina o se ignora con frecuencia en el correo. No puedes apoyarte en un único objetivo de renderizado. La accesibilidad del correo trata, por tanto, de construir mensajes que se degraden con elegancia: que sigan siendo legibles, navegables y significativos incluso cuando el diseño se desmorona, las imágenes no cargan o los estilos se descartan. Esa mentalidad defensiva es la base sobre la que se construye todo lo demás en esta guía, y es la razón por la que el correo pertenece a un programa específico de servicios de accesibilidad en lugar de integrarse en el trabajo web general.

Estructura semántica y un orden de lectura lógico

Incluso con todas las limitaciones, lo más valioso que puedes hacer por una persona usuaria de lector de pantalla es dar al correo una estructura clara y lineal. Los lectores de pantalla leen el contenido en orden del DOM, así que el orden de tu marcado es el orden en que se escucha tu mensaje. Si tu diseño coloca un banner promocional antes del mensaje real, el banner se anuncia primero, sin importar cómo se vea el diseño.

Usa elementos de encabezado reales para establecer la jerarquía. Un correo debe tener un encabezado de nivel superior lógico (normalmente el tema u oferta principal) como <h1>, con las secciones posteriores marcadas como <h2> y <h3>. Las personas usuarias de lectores de pantalla navegan por encabezados para escanear un mensaje, así que un esquema bien estructurado convierte un muro de texto en algo hojeable. No falsees encabezados con texto <span> grande y en negrita; visualmente puede parecer un encabezado, pero la tecnología de asistencia escucha texto de cuerpo corriente. Del mismo modo, usa marcado de lista genuino (<ul>, <ol>, <li>) para las listas, y define el idioma del documento con un atributo lang en el elemento <html> para que los lectores de pantalla usen la pronunciación y la voz correctas.

El orden de lectura también tiene que tener sentido por sí solo. Lee tu marcado de arriba abajo, ignorando todo el estilo, y pregúntate si sigue contando una historia coherente. Si lo hace, tienes una base sólida. Si el significado depende de la disposición visual, tienes trabajo por hacer, y ese trabajo suele empezar con las tablas de diseño.

Tablas de presentación y role=“presentation”

El diseño del correo se construye con tablas. No es una elección estilística; es un requisito de supervivencia, porque el diseño basado en tablas es el único enfoque que se renderiza de forma coherente en toda la matriz de clientes. El problema es que las tablas conllevan un significado semántico. Por defecto, un lector de pantalla anuncia una <table> como tabla de datos, lee el número de filas y columnas e intenta asociar las celdas con los encabezados. Para una tabla que existe únicamente para colocar un logotipo junto a un titular, ese anuncio es ruido, y a lo largo de un correo anidado de varias tablas se convierte en una experiencia agotadora y desorientadora.

La solución es decirle a la tecnología de asistencia que estas tablas son andamiaje de diseño, no datos. Añade role="presentation" a cada tabla usada para el diseño: <table role="presentation">. Esto elimina la semántica de la tabla para que los lectores de pantalla omitan los anuncios de filas y columnas y simplemente lean el contenido interior en orden. Es una de las técnicas más importantes y más frecuentemente omitidas en la accesibilidad del correo, y debe aplicarse a cada tabla de diseño, incluidas las anidadas, no solo al contenedor más externo.

Unas cuantas prácticas relacionadas refuerzan esto. No añadas summary, celdas de encabezado <th>, scope ni <caption> a las tablas de presentación: ese es marcado portador de significado reservado a las tablas de datos genuinas. Si tu correo contiene datos tabulares reales, como un recibo detallado, haz lo contrario: déjala como tabla de datos con encabezados <th> adecuados y atributos scope para que las relaciones se transmitan. El principio es la coherencia entre la apariencia y la semántica. Conseguir esto en una biblioteca de plantillas es delicado y fácil de regresar, por lo que es una parte central de nuestro trabajo de remediación de correo.

Imágenes y texto alternativo

Las imágenes cargan mucho peso en el correo, y muchos destinatarios las ven con las imágenes desactivadas por defecto: algunos clientes bloquean las imágenes remotas hasta que el usuario opta por verlas. Eso hace que el texto alternativo sea doblemente importante: es a la vez un requisito de accesibilidad y la alternativa que mantiene inteligible tu mensaje cuando las imágenes no cargan.

Cada elemento <img> necesita un atributo alt. Lo que va dentro depende del propósito de la imagen. Para una imagen informativa —una foto de producto, una infografía, un gráfico— el texto alternativo debe transmitir la misma información que aporta la imagen. «Zapatilla de correr azul, vista lateral» es más útil que «image1.png», y el texto alternativo de un gráfico debe resumir la conclusión, no solo etiquetarlo como gráfico. Para texto representado como imagen, lo que aún ocurre con los titulares promocionales, el texto alternativo debe reproducir las palabras exactamente, porque de lo contrario ese contenido es invisible para los lectores de pantalla y para cualquiera con las imágenes desactivadas.

Para imágenes decorativas —espaciadores, florituras de fondo, divisores que no aportan nada al significado— usa un atributo alt vacío, escrito como alt="". Esto indica explícitamente a los lectores de pantalla que omitan la imagen en lugar de anunciar un nombre de archivo. Omitir el atributo por completo no es lo mismo; un alt ausente a menudo hace que los lectores de pantalla lean la URL de la imagen, que es lo peor de ambos mundos. Ten especial cuidado con el patrón común de usar una imagen como botón o enlace: el texto alternativo de esa imagen debe describir la acción, como «Completa tu compra», no la imagen.

Un punto más específico del correo: nunca pongas información esencial solo en una imagen. Un código de cupón, un número de confirmación, un enlace de cancelación de suscripción, la llamada a la acción principal: si cualquiera de estos existe solo como píxeles, desaparece para los usuarios con imágenes desactivadas y lectores de pantalla. Mantén el contenido crítico como texto en vivo y seleccionable.

Contraste y modo oscuro

El texto tiene que ser legible, lo que significa que tiene que cumplir los requisitos de contraste. WCAG 2.2 pide una relación de contraste de al menos 4,5:1 para texto normal y 3:1 para texto grande frente a su fondo. El texto gris claro sobre fondo blanco —un favorito perenne del diseño minimalista de correo— falla con frecuencia, al igual que los botones pálidos y los colores de enlace de bajo contraste. Estos umbrales se aplican al correo igual que a la web, y los mismos criterios de éxito de WCAG 2.2 son la referencia; nuestra visión general más amplia de conformidad con WCAG explica cómo encajan esos criterios.

El correo añade una complicación que la web en su mayoría no tiene: el modo oscuro. Muchos clientes —Apple Mail, Outlook y Gmail entre ellos— transforman automáticamente los correos cuando el usuario tiene activado el modo oscuro. Algunos simplemente intercambian el fondo; otros invierten o recolorean agresivamente tu paleta, a veces parcialmente. El resultado es que un botón con texto oscuro sobre un color de marca claro puede acabar con texto oscuro sobre un fondo oscuro invertido, dejando el contraste en nada. El texto negro dentro de una caja de color puede volverse invisible. Los logotipos con fondo transparente pueden desaparecer sobre un lienzo oscuro.

No hay un control universal sobre el modo oscuro, y las técnicas que existen varían según el cliente, pero los principios defensivos son estables. Diseña teniendo ambos modos en mente. Evita el negro puro o el blanco puro como colores base, ya que no dejan margen para que el cliente se ajuste. Da a los logotipos y gráficos clave un contorno contrastante o una placa de fondo sólida para que sobrevivan a la inversión. Prueba el resultado renderizado real en modo oscuro en cada cliente importante en lugar de confiar en que tu diseño de modo claro se traduzca. El objetivo es que el texto y los elementos interactivos se mantengan por encima del umbral de contraste sin importar cómo los invierta el cliente.

Enlaces descriptivos y botones accesibles

Las personas usuarias de lectores de pantalla a menudo abren una lista de todos los enlaces de un mensaje para navegar o decidir adónde ir. En esa lista, el texto del enlace aparece despojado de su contexto circundante. Un mensaje lleno de «Haz clic aquí», «Leer más» y «Más información» produce un inventario inútil de entradas idénticas y sin sentido. El texto de cada enlace debe tener sentido por sí solo: «Lee nuestro informe de sostenibilidad de primavera» o «Sigue tu pedido» dice al usuario exactamente adónde lleva el enlace sin ninguna frase circundante.

Lo mismo se aplica a los botones, que en el correo suelen ser enlaces estilizados para parecer botones, a menudo construidos con la técnica del «botón a prueba de balas» usando tablas anidadas y colores de fondo para que se rendericen en todos los clientes. Sea cual sea la construcción, el nombre accesible del botón debe describir su acción. Un botón vacío o vago, o uno cuyo texto vive solo en una imagen de fondo, es un callejón sin salida para la tecnología de asistencia. Si el botón se basa en una imagen, la acción pertenece al texto alternativo de la imagen.

Haz que los objetivos de enlaces y botones sean lo bastante grandes como para tocarlos cómodamente: WCAG 2.2 introdujo un tamaño mínimo de objetivo, y en el móvil un objetivo de toque demasiado pequeño frustra a todos, no solo a los usuarios con deficiencias motoras. Asegúrate de que los enlaces sean distinguibles por algo más que el color, ya que los enlaces solo con color fallan para usuarios con baja visión o daltonismo; un subrayado es la pista más segura. Y da a cada enlace un destino real y funcional en lugar de un marcador de posición. El texto de enlace vago es uno de los fallos más comunes que vemos, y aparece también en la web, no solo en el correo; nuestro resumen de problemas de accesibilidad comunes que evitar cubre el mismo patrón en un contexto más amplio.

El preheader y la experiencia de vista previa

El preheader —a veces llamado texto de vista previa— es el fragmento de texto que aparece junto a o debajo de la línea de asunto en la bandeja de entrada, antes de que se abra el mensaje. Muchos correos lo desperdician, dejando que tome por defecto el texto que casualmente aparezca primero: una línea de «¿El correo no se muestra correctamente?», un enlace de «cancelar suscripción» o una cadena de texto alternativo vacío. Para las personas usuarias de lectores de pantalla que navegan por su bandeja de entrada, y para todos los que deciden si abrir, ese preheader desperdiciado es una oportunidad perdida de comunicar.

Escribe un preheader deliberado y significativo que resuma el propósito del correo, y colócalo como el primer contenido de texto en el cuerpo para que sea lo que la bandeja de entrada recoja. La técnica estándar es un bloque de texto oculto cerca de la parte superior del correo, estilizado para estar visualmente oculto pero aún disponible para los clientes y la tecnología de asistencia. Ten cuidado con cómo lo ocultas: un preheader mal ocultado puede aparecer como una línea visible no deseada o ser omitido por completo por los lectores de pantalla. Rellénalo adecuadamente para que el contenido posterior de la bandeja de entrada no filtre texto adyacente en la vista previa.

Trata el preheader como parte de la arquitectura de información del mensaje. Combinado con una línea de asunto clara y un fuerte encabezado de apertura, da a cada destinatario —vidente o no— una sensación rápida y precisa de lo que es el correo y por qué importa.

Diseño adaptable y zoom

Los correos se leen tanto en teléfonos como en ordenadores de escritorio, y los leen personas que hacen zoom para ampliar el texto. Ambos exigen que el diseño se adapte. Un diseño fijo y ancho que obliga a desplazarse horizontalmente en una pantalla pequeña, o que se rompe cuando un usuario aumenta el tamaño del texto, es una barrera, y WCAG 2.2 tiene criterios tanto para el reajuste como para el espaciado del texto que se aplican aquí.

Construye los correos para que sean adaptables: un diseño de una sola columna en pantallas estrechas es casi siempre la opción más robusta y accesible, porque preserva el orden de lectura y evita el contenido lado a lado que se desmorona de forma impredecible. Donde uses consultas de medios para cambiar de diseño, recuerda que algunos clientes las ignoran, así que el renderizado por defecto debe seguir siendo utilizable. Define tamaños de fuente lo bastante grandes para leer sin hacer zoom —el texto de cuerpo por debajo de aproximadamente 14 a 16 píxeles es difícil para muchas personas en el móvil— y evita fijar la altura de línea o el espaciado entre letras tan ajustadamente que el texto ampliado se solape o se recorte.

Prueba qué ocurre cuando un usuario hace zoom o aumenta el tamaño de fuente del sistema de su dispositivo. El contenido debe reajustarse y seguir siendo legible en lugar de desbordar su contenedor o desaparecer detrás de otros elementos. La recompensa es un correo que funciona no solo para usuarios con baja visión, sino para todos los que leen en una pantalla pequeña en condiciones imperfectas.

Pruebas en clientes y lectores de pantalla

No puedes verificar la accesibilidad del correo inspeccionando solo el código, porque todo el desafío es que los clientes renderizan el mismo código de forma diferente. Las pruebas tienen que hacerse en una matriz representativa de clientes y tecnologías de asistencia, en las condiciones que usan los destinatarios reales.

Cubre como mínimo los clientes principales: Outlook (escritorio en Windows, más las versiones web y nuevas), Gmail (web y la app móvil) y Apple Mail (macOS e iOS). Para cada uno, comprueba el renderizado tanto en modo claro como oscuro, con imágenes activadas y desactivadas, y con zoom aumentado. Luego superpón los lectores de pantalla: VoiceOver con Apple Mail en macOS e iOS, NVDA o JAWS con Outlook y Gmail en Windows, y TalkBack con la app de Gmail en Android. Escucha el correo como lo haría una persona usuaria de lector de pantalla: ¿se anuncian los encabezados, es lógico el orden de lectura, están en silencio las tablas de diseño, tienen sentido los enlaces en la lista de enlaces, anuncian las imágenes texto alternativo útil o permanecen calladas cuando son decorativas?

Las comprobaciones automatizadas tienen su lugar —pueden señalar rápidamente atributos alt ausentes, bajo contraste y atributos de idioma faltantes en muchas plantillas— pero no pueden juzgar si el texto alternativo es significativo, si el orden de lectura cuenta la historia correcta o si el nombre de un botón describe su acción. Ese juicio requiere pruebas manuales, idealmente incluyendo pruebas por parte de personas que usan tecnología de asistencia a diario. Nuestra guía de auditorías manuales de accesibilidad explica por qué las pruebas humanas son irremplazables, y nuestras auditorías por personas con discapacidad aportan exactamente esa perspectiva de experiencia vivida al correo.

Una advertencia: no te dejes tentar por los widgets de «superposición» de accesibilidad que prometen conformidad instantánea. No funcionan para los sitios web, y son irrelevantes para el correo, donde no hay una página en la que inyectar un script. La verdadera accesibilidad del correo viene de arreglar el marcado, no de un añadido.

Remediar plantillas a nivel del ESP

Arreglar un correo es útil. Arreglar la fuente que genera todos los correos es transformador. La mayoría de las organizaciones envían a través de un proveedor de servicios de correo electrónico —Mailchimp, Klaviyo, Salesforce Marketing Cloud, Braze y similares— donde las campañas se ensamblan a partir de plantillas maestras, módulos reutilizables y bloques de contenido de arrastrar y soltar. Si esas plantillas subyacentes llevan las correcciones de accesibilidad, cada envío futuro las hereda automáticamente, y el equipo de marketing no tiene que recordar una lista de verificación para cada campaña.

Este es el lugar más rentable para invertir. Remedia la plantilla maestra para que las tablas de diseño lleven role="presentation", el atributo de idioma esté definido, la estructura del preheader esté en su sitio y el andamiaje de encabezados sea correcto. Remedia cada módulo reutilizable —el bloque hero, la tarjeta de artículo, el botón, el pie de página— para que lo que el equipo arrastre sea accesible por construcción. Establece patrones para el texto alternativo de modo que se solicite a los editores que lo escriban, e incorpora colores con contraste seguro y conscientes del modo oscuro en la paleta de marca que usan las plantillas.

El inconveniente es que los constructores de arrastrar y soltar también pueden regresar la accesibilidad: un constructor puede eliminar role="presentation", estropear el marcado al exportar o dejar que un editor pegue un bloque inaccesible. Así que la remediación de plantillas debe ir acompañada de gobernanza: directrices, pasos de revisión y nuevas pruebas periódicas a medida que el ESP y su comportamiento de exportación cambian. Ahí es donde integrar la accesibilidad en el flujo de trabajo da sus frutos; nuestro servicio de mejora de procesos de accesibilidad ayuda a los equipos a hacer del correo accesible la norma en lugar de una ocurrencia tardía, y la consultoría de accesibilidad lo alinea con tu programa de cumplimiento más amplio. Para las organizaciones sujetas a la Ley Europea de Accesibilidad, las comunicaciones accesibles con los clientes son parte del panorama, lo que expone nuestra visión general de conformidad con la EAA.

QualiBooth combina software de escaneo de accesibilidad para los problemas que las máquinas detectan de forma fiable con remediación manual experta para las decisiones de criterio que no pueden tomar, en sitios web, documentos y correo por igual. Si tus correos son parte de cómo atiendes a tus clientes, merecen el mismo rigor que el resto de tu patrimonio digital.

Conclusión

La accesibilidad del correo no es una versión más pequeña de la accesibilidad web: es una disciplina relacionada pero distinta, moldeada por un panorama de clientes fragmentado, diseños basados en tablas y motores de renderizado que ignoran gran parte de la web moderna. La buena noticia es que las técnicas están bien establecidas: estructura semántica y un esquema de encabezados sólido, role="presentation" en cada tabla de diseño, texto alternativo significativo con alt vacío para la decoración, contraste que sobrevive al modo oscuro, enlaces y botones que se describen a sí mismos, un preheader deliberado, diseños adaptables que resisten el zoom y pruebas disciplinadas en clientes y lectores de pantalla. Aplícalas a nivel de plantilla y la accesibilidad deja de ser una tarea por campaña y se convierte en una propiedad de tu sistema.

La recompensa es real. Los correos accesibles llegan a más personas, se leen con claridad con las imágenes desactivadas y tienden a rendir mejor porque la claridad y la robustez ayudan a todos. Si quieres ayuda, nuestro servicio de remediación de correo puede auditar tus plantillas, arreglarlas a nivel del ESP y verificar el resultado en toda la matriz de clientes, y puedes solicitar una demo o ejecutar un escaneo gratuito de tu sitio web para ver dónde está el resto de tu patrimonio digital.

Preguntas frecuentes

¿Realmente necesito role="presentation" en cada tabla de diseño? Sí. Sin él, los lectores de pantalla anuncian cada tabla de diseño como tabla de datos, leyendo los recuentos de filas y columnas e interrumpiendo el flujo. Como los diseños de correo anidan tablas, el atributo tiene que estar en cada tabla de diseño, no solo en el contenedor exterior. Las tablas de datos genuinas, como los recibos, conservan en cambio su semántica de datos.

¿Qué debo poner en el texto alternativo de una imagen decorativa? Usa un atributo alt vacío, escrito alt="", para que los lectores de pantalla omitan la imagen. No omitas el atributo por completo, porque un alt ausente a menudo hace que se lea en voz alta el nombre de archivo o la URL de la imagen.

¿Cómo evito que el modo oscuro estropee mi correo? No puedes controlar por completo cómo maneja cada cliente el modo oscuro, pero puedes diseñar de forma defensiva: evita el negro y el blanco puros, da a los logotipos un fondo o contorno contrastante, mantén el contraste por encima de los umbrales de WCAG 2.2 y prueba el resultado renderizado en modo oscuro en cada cliente importante en lugar de suponer que tu diseño de modo claro se trasladará.

¿Puede una herramienta automatizada hacer mi correo accesible? Las herramientas automatizadas detectan algunos problemas —atributos alt ausentes, bajo contraste, ajustes de idioma faltantes— pero no pueden juzgar si el texto alternativo es significativo, si el orden de lectura tiene sentido o si los enlaces y botones describen su propósito. Eso requiere pruebas manuales con lectores de pantalla. Los widgets de superposición de accesibilidad no son una solución y no son aplicables al correo.

¿Es mejor arreglar correos individuales o plantillas? Plantillas. Remediar las plantillas maestras y los módulos reutilizables en tu ESP significa que cada envío futuro hereda las correcciones, lo que es mucho más rentable que arreglar campañas una a una. Acompáñalo de gobernanza para que los constructores de arrastrar y soltar no reintroduzcan problemas.