Correo electrónico y boletines accesibles

El correo electrónico es el canal digital más usado por cualquier organización y uno de los menos cuidados en accesibilidad. Los boletines se maquetan como una sola imagen, los correos internos llevan capturas de pantalla en lugar de texto y los enlaces dicen «pulse aquí». Y, a diferencia de la web, en el correo no hay un equipo técnico que corrija después: lo que se envía, se envía. Esta lección cubre los correos cotidianos, los boletines en HTML y cómo comprobarlos antes de pulsar «Enviar».

Correos cotidianos

No hace falta HTML sofisticado para que un correo sea accesible o inaccesible. Lo que importa:

• Asunto claro y concreto: «Acta de la reunión del 12 de marzo y tareas pendientes», no «Reunión». Es lo primero que lee todo el mundo y lo único que lee quien recibe cien correos al día.
• Lo importante en las primeras líneas: qué se pide, a quién y para cuándo.
• Estructura: párrafos cortos, listas reales (con la herramienta de lista del cliente de correo, no con guiones), y si el correo es largo, títulos usando los estilos del editor (Outlook y Gmail permiten encabezados en algunos casos; si no, al menos párrafos cortos con una frase destacada en negrita al inicio).
• Texto, no capturas: si copias un dato de una web o de un documento, pégalo como texto. Una captura de pantalla de una tabla es ilegible para un lector de pantalla y para quien amplía el texto.
• Enlaces con sentido: «Consulta el calendario de formación» en lugar de la URL cruda o «aquí».
• Adjuntos accesibles: si adjuntas un documento, que sea accesible (siguiente lección) y menciona en el texto qué es y qué contiene.
• Firma sobria: texto, no imagen; si incluye logotipo, con alt; sin banners con texto en imagen.
• Fuente de 16 píxeles (14 como mínimo), color negro o muy oscuro sobre blanco, sin fondos de color ni papel tapiz.

Boletines en HTML

Los boletines (newsletters) se envían a miles de personas y se construyen con herramientas como Mailchimp, Brevo, Acumbamail o plantillas propias. El HTML de correo es técnicamente arcaico (tablas para maquetar, CSS en línea) porque los clientes de correo, en especial Outlook, soportan muy poco. Aun así, se puede hacer accesible:

Estructura y semántica

• Declara el idioma: <html lang="es"> (y, en las herramientas, el ajuste de idioma de la campaña).
• Usa encabezados reales (<h1>, <h2>) para los títulos de las secciones, no párrafos en negrita.
• Las tablas de maquetación deben llevar role="presentation" para que el lector de pantalla no anuncie «tabla de 3 filas y 1 columna» a cada bloque. Las herramientas serias lo hacen por defecto; compruébalo en una vista previa del código.
• Una sola columna: funciona en móvil, en zoom y en lectura lineal.

Imágenes

• Texto alternativo en todas: muchos clientes y servidores corporativos (Outlook de escritorio, por ejemplo) bloquean las imágenes por defecto, así que el alt es también lo que ven muchas personas sin discapacidad hasta que las descargan.
• Nunca el boletín entero como una imagen. Es la práctica más excluyente: sin imágenes cargadas no hay nada, y con ellas tampoco para quien no ve.
• Nada de texto en imágenes para titulares o botones (1.4.5). Los botones «a prueba de balas» se construyen con celdas de tabla y texto real.

Texto y enlaces

• Tamaño mínimo de 16 px en el cuerpo, interlineado de 1,5, contraste de 4,5:1 como mínimo. Evita texto gris claro sobre blanco, el pecado capital de los boletines «elegantes».
• Enlaces subrayados y con texto descriptivo. En muchos boletines todos los enlaces son «Leer más»; incluye el título de la noticia.
• Enlace de «ver en el navegador» al principio y de baja al final, en texto.
• Versión en texto plano: casi todas las herramientas la generan; revísala, porque es la que leen algunos clientes y la que sirve de respaldo.

Modo oscuro

Los clientes de correo aplican su propio modo oscuro, a veces invirtiendo colores de forma impredecible. Prueba el boletín en modo oscuro en Gmail, Outlook y Apple Mail: logotipos negros que desaparecen, textos que pierden contraste. Los logotipos en PNG con transparencia y un trazo claro, y los colores de texto definidos explícitamente, reducen los problemas.

<!-- Bloque de boletín accesible (simplificado) -->
<table role="presentation" width="100%">
  <tr><td>
    <h2 style="font-size:22px;color:#1A1A1A;">Nueva convocatoria de ayudas</h2>
    <p style="font-size:16px;line-height:1.5;color:#1A1A1A;">Abierto el plazo hasta el 30 de junio.</p>
    <a href="https://ejemplo.es/ayudas" style="color:#0B3D91;text-decoration:underline;">Consultar las bases de la convocatoria</a>
  </td></tr>
</table>

Cómo comprobarlo antes de enviar

• Envíate una prueba y léela con las imágenes bloqueadas: ¿se entiende todo?
• Ábrela en el móvil con el tamaño de letra del sistema aumentado: ¿hay desplazamiento horizontal o texto cortado?
• Actívala en modo oscuro: ¿se ve el logotipo? ¿Mantiene contraste el texto?
• Recorre los enlaces con Tab: ¿tienen sentido leídos solos?
• Pasa el HTML por un comprobador (las herramientas de envío suelen incluir uno básico; también puedes pegar el código en un validador o en la pestaña de accesibilidad del navegador).

Resumen

• Correos cotidianos: asunto concreto, lo importante primero, listas reales, texto en lugar de capturas, enlaces con sentido, adjuntos accesibles.
• Boletines: idioma declarado, encabezados reales, tablas de maquetación con role="presentation", una columna.
• Alt en todas las imágenes, nunca el boletín como imagen, botones con texto real, 16 px y contraste 4,5:1.
• Enlaces subrayados y descriptivos, versión en texto plano revisada, prueba en modo oscuro.
• Antes de enviar: prueba con imágenes bloqueadas, en móvil con letra grande, en modo oscuro y recorriendo los enlaces.