El ticket de soporte al cliente fue desconcertante al principio. "No puedo usar sus emails." La persona explicó que era ciega y usaba un lector de pantalla. Los bellamente diseñados emails de la empresa eran un muro de "imagen imagen imagen enlace enlace enlace": sin texto alternativo, sin estructura semántica, sin forma de entender el contenido.
La accesibilidad en emails no es opcional. Más allá del imperativo ético de incluir a todas las personas, hay requisitos legales en muchas jurisdicciones. Y en la práctica, los emails accesibles son mejores emails: estructura más clara, mejor experiencia móvil y un renderizado más fiable.
Esta lista de verificación cubre las consideraciones técnicas y de diseño que hacen que los emails funcionen para todas las personas.
Imágenes y multimedia
Todas las imágenes tienen texto alternativo. Cada etiqueta <img> necesita un atributo alt. Describe lo que muestra la imagen, no solo que es una imagen. "Foto de producto de zapatillas de correr azules" es útil. "Imagen" no lo es.
Las imágenes decorativas tienen alt vacío. Las imágenes que no transmiten información (espaciadores, bordes decorativos) deben tener alt="" para que los lectores de pantalla las omitan. No omitas el atributo alt por completo: eso hace que los lectores de pantalla lean el nombre de archivo.
El texto alternativo es conciso pero completo. Apunta a menos de 125 caracteres. Describe la información esencial. Para imágenes complejas como gráficos, proporciona un resumen en texto cerca.
Las imágenes no son la única forma de transmitir información. Si una imagen contiene texto, ese texto también debe aparecer como texto real. Si un gráfico muestra datos, resume los hallazgos clave en texto.
Los GIFs animados se usan con moderación. El contenido intermitente o que cambia rápidamente puede desencadenar convulsiones. Si usas animación, asegúrate de que no parpadee más de tres veces por segundo. Proporciona una forma de pausar la animación si es posible.
Texto y tipografía
El tamaño de fuente es legible. Mínimo 14px para el cuerpo del texto, idealmente 16px. El texto más pequeño es difícil para muchas personas, no solo para quienes tienen discapacidad visual.
La altura de línea es adecuada. Al menos 1.5x el tamaño de fuente. El texto apretado es difícil de leer para cualquiera y especialmente para personas con dislexia o discapacidades cognitivas.
El contraste de color cumple con los estándares WCAG. El texto debe tener al menos una relación de contraste de 4.5:1 con su fondo (3:1 para texto grande). Usa una herramienta de verificación de contraste para confirmarlo.
El color no es el único indicador. No dependas solo del color para transmitir significado. "Los campos en rojo son obligatorios" falla para personas con daltonismo. Usa íconos, etiquetas de texto o patrones además del color.
El texto se puede redimensionar. Usa unidades relativas (em, rem, %) en lugar de píxeles fijos cuando sea posible. Las personas que necesitan texto más grande deberían poder obtenerlo.
Estructura y semántica
Los encabezados crean una jerarquía lógica. Usa etiquetas de encabezado (h1, h2, h3) para estructurar el contenido. No te saltes niveles. Las personas que usan lectores de pantalla navegan por encabezados: una jerarquía correcta hace que esto funcione.
Las tablas se usan para datos, no para maquetación. Las tablas de maquetación confunden a los lectores de pantalla. Usa tablas solo para datos tabulares reales. Para la maquetación, usa otras técnicas (aunque las limitaciones del HTML en email lo hacen desafiante).
Las tablas de datos tienen encabezados. Usa <th> para las celdas de encabezado con scope="col" o scope="row". Esto le indica a los lectores de pantalla cómo asociar las celdas de datos con sus encabezados.
El orden de lectura es lógico. Los lectores de pantalla siguen el orden del DOM, no el visual. Asegúrate de que el orden HTML tenga sentido cuando se lea linealmente, incluso si el CSS reorganiza visualmente las cosas.
Se especifica el idioma. Incluye lang="en" (o el código de idioma apropiado) en el elemento HTML. Esto ayuda a los lectores de pantalla a usar la pronunciación correcta.
Enlaces y botones
El texto de los enlaces es descriptivo. "Haz clic aquí" y "Leer más" no significan nada fuera de contexto. Quienes usan lectores de pantalla suelen navegar por enlaces: "Lee nuestra política de privacidad" les dice a dónde lleva el enlace.
Los enlaces son visualmente distinguibles. Los subrayados son el indicador más fiable. El color por sí solo no es suficiente para personas con daltonismo.
Las áreas táctiles son lo suficientemente grandes. Mínimo 44x44 píxeles para elementos táctiles. Los enlaces pequeños son difíciles para personas con discapacidades motoras y frustrantes para cualquiera en móvil.
Los enlaces tienen estados de foco. Las personas que usan teclado necesitan ver qué elemento tiene el foco. Asegúrate de que los estilos de foco sean visibles y distintivos.
Formularios (si corresponde)
Los campos del formulario tienen etiquetas. Cada input necesita una etiqueta asociada. Usa <label for="fieldid"> o envuelve el input dentro del elemento label.
Los mensajes de error son claros. Explica qué salió mal y cómo solucionarlo. No solo resaltes el campo en rojo: proporciona una explicación en texto.
Los campos obligatorios están indicados. Marca claramente los campos obligatorios, usando texto ("obligatorio") y no solo asteriscos o color.
Pruebas de accesibilidad
Prueba con un lector de pantalla. NVDA (Windows, gratis), VoiceOver (Mac/iOS, integrado) y TalkBack (Android, integrado) son las opciones principales. Escucha cómo suena tu email, no solo cómo se ve.
Prueba la navegación con teclado. ¿Puedes alcanzar todos los elementos interactivos usando Tab? ¿El orden de foco es lógico? ¿Puedes activar enlaces y botones con Enter?
Prueba con las imágenes desactivadas. Muchos clientes de email bloquean las imágenes por defecto. ¿Tu email es comprensible sin ellas?
Prueba con diferentes niveles de zoom. Amplía al 200% en tu navegador. ¿El diseño sigue funcionando? ¿El texto sigue siendo legible?
Usa herramientas automatizadas. WAVE, axe y herramientas similares detectan problemas comunes. No lo detectan todo—las pruebas manuales siguen siendo necesarias—pero son un buen punto de partida.
Consideraciones específicas del email
El texto del preheader es significativo. Los lectores de pantalla pueden anunciar el texto del preheader. Hazlo útil, no solo "Ver en el navegador" o espacios en blanco.
La versión en texto plano es completa. Algunas personas prefieren o requieren texto plano. Asegúrate de que tu versión en texto plano contenga toda la información de la versión HTML.
La opción para darse de baja es fácil de encontrar. No la ocultes en texto diminuto. Las personas que quieran darse de baja deberían poder encontrar la opción fácilmente.
Errores comunes
Usar imágenes con texto. El texto en imágenes no se puede redimensionar, no se refluye y no es legible por lectores de pantalla. Usa texto real siempre que sea posible.
Texto justificado. La justificación completa crea espacios irregulares que son difíciles para personas con dislexia. Usa texto alineado a la izquierda.
"Decisiones de diseño" de bajo contraste. El texto gris claro sobre fondos blancos puede verse elegante pero no cumple con los requisitos de accesibilidad. Prioriza la legibilidad sobre la estética.
Faltan enlaces de salto. Para emails largos, un enlace "saltar al contenido principal" ayuda a quienes usan teclado a omitir navegación repetitiva.
Frequently asked questions
¿Se aplican los requisitos de accesibilidad a todos los emails?
Los requisitos legales varían según la jurisdicción y el contexto. Pero la accesibilidad beneficia a todas las personas—estructura más clara, mejor experiencia móvil, renderizado más fiable. No hay inconvenientes en hacer que los emails sean accesibles.
¿Cómo pruebo emails con un lector de pantalla?
Envíate el email, ábrelo en un cliente de correo y usa un lector de pantalla (VoiceOver en Mac, NVDA en Windows). Escucha todo el email. Anota dónde falta información, qué confunde o está en el orden incorrecto.
¿Cuál es la relación de contraste mínima para el texto?
WCAG AA requiere 4.5:1 para texto normal y 3:1 para texto grande (18px+ o 14px+ en negrita). WCAG AAA requiere 7:1 y 4.5:1 respectivamente. Usa herramientas como el comprobador de contraste de WebAIM para verificar.
¿Puedo usar CSS para funciones de accesibilidad en email?
El soporte de CSS en email es limitado e inconsistente. Basa tu implementación en atributos HTML (alt, lang, scope) en lugar de soluciones solo con CSS. Prueba en distintos clientes para asegurarte de que las funciones de accesibilidad funcionen.