Accesibilidad en correos HTML: qué decide cada persona del equipo

Cómo suena un correo con lector de pantalla

Quien usa un lector de pantalla no ve la vista previa que aprobaste: recorre el contenido en el orden del código, y en un correo ese orden lo fija la estructura de celdas de la tabla. WCAG lo recoge en el criterio 1.3.2, Secuencia significativa: cuando el orden afecta al sentido, tiene que poder determinarse de forma programática. Por eso una campaña con la oferta a la derecha y la explicación a la izquierda puede leerse al revés, aunque en pantalla se vea bien. El primer ejercicio que merece la pena es leer el correo de arriba abajo en voz alta, solo con el código delante, y comprobar que cada frase tiene sentido en ese orden.

La segunda diferencia es la manera de moverse. Los lectores permiten saltar de titular en titular o abrir una lista con todos los enlaces del mensaje. Esa lista es la prueba más rápida para un redactor: si aparecen cinco entradas que dicen «Haz clic aquí», nadie sabe a dónde lleva ninguna. W3C lo formula en el criterio 2.4.4, Propósito de los enlaces (en contexto): la finalidad de cada enlace debe poder deducirse del texto del enlace o de su contexto determinado programáticamente.

Quién decide qué

En un equipo de marketing, el HTML lo toca poca gente, de modo que conviene saber qué parte de la accesibilidad se resuelve en el editor y cuál en la plantilla. Esta tabla reparte las tareas; sirve como lista de comprobación para el día en que se aprueba una plantilla nueva.

Un ejemplo completo: antes y después

Este es el tipo de plantilla que llega a la bandeja sin revisión: una imagen sin descripción, un titular hecho con negrita y un gris claro, y un enlace que no dice a dónde va.

<!-- Antes: lo que suele salir de una plantilla sin revisar -->
<html>
<body>
  <table width="600">
    <tr><td><img src="banner-rebajas.jpg" width="600"></td></tr>
    <tr><td><b style="font-size:22px;color:#999999;">GRANDES REBAJAS</b></td></tr>
    <tr><td>Hasta el 40 % en toda la tienda hasta el domingo.</td></tr>
    <tr><td><a href="https://tienda.example/rebajas">Haz clic aquí</a></td></tr>
  </table>
</body>
</html>

Y esta es la misma pieza corregida. El diseño no cambia: la imagen sigue arriba, el titular sigue en rojo y el botón conserva su color. Cambian el idioma, el rol de la tabla, el titular real, el alt con el mensaje completo y el texto del botón.

<!-- Después: mismo diseño, pero entendible sin verlo -->
<html lang="es" dir="ltr">
<body lang="es" dir="ltr">
  <table role="presentation" width="600" style="max-width:600px;" cellspacing="0" cellpadding="0" border="0">
    <tr>
      <td>
        <img src="banner-rebajas.jpg" width="600" alt="Rebajas de otoño: hasta el 40 % en toda la tienda hasta el domingo" style="display:block; width:100%; height:auto;">
      </td>
    </tr>
    <tr>
      <td style="padding:16px; font-family:Arial, Helvetica, sans-serif; font-size:16px; line-height:24px; color:#333333;">
        <h1 style="margin:0 0 8px 0; font-size:24px; line-height:30px; color:#b3261e;">Rebajas de otoño</h1>
        <p style="margin:0 0 16px 0;">Hasta el 40 % en toda la tienda, solo hasta el domingo 12 de octubre.</p>
        <a href="https://tienda.example/rebajas" style="display:inline-block; padding:12px 24px; background-color:#b3261e; color:#ffffff; font-weight:bold; text-decoration:none;">Ver las ofertas de otoño</a>
      </td>
    </tr>
  </table>
</body>
</html>

En el segundo ejemplo, el alt repite lo que dice la imagen del cartel, porque W3C pide en su tutorial de imágenes informativas que la alternativa transmita lo mismo que la imagen. El botón dice «Ver las ofertas de otoño» y no «Haz clic aquí», y su blanco sobre #b3261e da 6,54:1, de modo que cumple el mínimo de 4,5:1 del criterio 1.4.3 Contraste (mínimo). El gris #999999 del titular original, en cambio, da 2,85:1 sobre blanco.

El idioma: lang="es", es-ES o es-419

W3C explica en su guía sobre cómo declarar el idioma en HTML que la etiqueta va en el elemento html, no en body, porque el cuerpo no cubre la cabecera. Pero en correo conviene repetirla en body, ya que algunos clientes quitan el envoltorio al mostrar el mensaje; la documentación de React Email lo advierte con esas palabras. En caniemail, el atributo lang aparece como compatible en Gmail, Apple Mail y Outlook, y como parcial en Yahoo y AOL, donde la nota aclara que no funciona sobre td.

Respecto a la variante, la guía de W3C sobre etiquetas de idioma da una regla simple: mantén la etiqueta lo más corta posible y añade subetiquetas solo si distinguen algo en tu contexto. Para una lista hispanohablante mezclada, es basta. Si segmentas por región y el texto cambia de verdad, es-ES designa el español de España y es-419 el de América Latina.

Cuando aparece otro idioma dentro del texto, el criterio 3.1.2, Idioma de las partes, pide poder determinar el idioma de cada pasaje, salvo nombres propios, términos técnicos, palabras de idioma indeterminado y palabras que ya forman parte del vocabulario del texto que las rodea. En un correo en español, «newsletter» o «online» casi seguro entran en esa excepción; una frase entera en inglés, no.

<p>Nuestro <span lang="en">welcome kit</span> llega con tu primer pedido.</p>
<p>El código de la tarjeta es <span lang="en">SPRING-24</span>: escríbelo tal cual.</p>

Tablas: de maquetación y de datos

Las tablas de maquetación llevan role="presentation"; la especificación WAI-ARIA lo define como un elemento cuya semántica nativa no se asigna a la API de accesibilidad. En caniemail, role funciona en Gmail y Apple Mail, aparece en Outlook para Windows como resultado no probado en vivo (solo se miró el código procesado) y es parcial en Yahoo y AOL, donde solo vale en la etiqueta table. Pon el atributo en la tabla, nunca en tr o td.

Si la tabla sí contiene datos (el resumen de un pedido, una factura, una comparación de planes), conserva su semántica. El tutorial de tablas de W3C pide marcar las cabeceras con th, las celdas con td y usar scope para indicar si la cabecera es de columna o de fila, además de un título (caption).

<table width="100%" cellspacing="0" cellpadding="8" border="0" style="border-collapse:collapse;">
  <caption style="text-align:left; padding-bottom:8px;">Resumen de tu pedido 4812</caption>
  <tr>
    <th scope="col" align="left">Producto</th>
    <th scope="col" align="right">Unidades</th>
    <th scope="col" align="right">Importe</th>
  </tr>
  <tr>
    <th scope="row" align="left">Zapatillas de trail</th>
    <td align="right">1</td>
    <td align="right">89,90 €</td>
  </tr>
</table>

Titulares y estructura

Los titulares funcionan en todos los clientes que registra caniemail: su ficha de h1 a h6 no muestra ningún cliente sin compatibilidad. Los elementos de sección de HTML5 son otra cosa: según su ficha de semántica HTML5, Gmail los admite solo en parte (no admite main, nav, details ni summary y sustituye sus etiquetas por u), Outlook para Windows no los admite y Yahoo elimina las etiquetas. Los titulares, por tanto, tienen que hacer el trabajo de la navegación.

En el editor visual, la regla práctica es no fabricar titulares con negrita y cuerpo 24: el bloque «Título» o «Heading» genera una etiqueta de verdad, y la negrita grande genera solo un párrafo de aspecto llamativo. El tutorial de titulares de W3C añade que se anidan por rango y que saltarse niveles, de un h2 a un h4, puede confundir.

Imágenes: describir la función, no la foto

El criterio 1.1.1, Contenido no textual, pide una alternativa textual que cumpla el mismo propósito y que lo puramente decorativo pueda ser ignorado por la tecnología de apoyo. W3C reparte las imágenes en cuatro tipos y cada correo suele tener los cuatro. La imagen informativa lleva una descripción de lo que aporta; la decorativa lleva alt="" (el atributo vacío, nunca omitido, porque algunos lectores anuncian el nombre del archivo si falta); la funcional, como un icono dentro de un enlace, describe la acción («Descargar la factura 4812 en PDF») y no el dibujo; y la compleja, como un gráfico con datos, necesita una frase con la conclusión, y si hace falta, los datos en una tabla de texto.

Un detalle propio del correo: muchos clientes bloquean las imágenes hasta que el lector las autoriza, y ahí el alt pasa a ser el único contenido visible. Dale tamaño y color en la etiqueta img para que la línea de texto se lea sin la imagen, y no pongas la fecha, el código ni el precio solo dentro de una imagen.

Contraste: cinco pares calculados

WCAG 1.4.3 exige 4,5:1 para el texto normal y 3:1 para el texto grande, que la página de comprensión define como 18 puntos o 14 puntos en negrita, es decir, unos 24 px y unos 18,5 px. Estos pares se han calculado con la fórmula de luminancia relativa de WCAG:

Los controles tienen su propio mínimo: el criterio 1.4.11, Contraste de elementos no textuales, pide 3:1 entre un componente de interfaz y los colores que lo rodean, y el 1.4.1, Uso del color, prohíbe que el color sea el único medio visual para transmitir información: un precio en rojo necesita además la palabra «agotado» o un icono con texto. Para el modo oscuro, que puede romper un par que cumplía, mira la guía de modo oscuro.

Lo que los clientes conservan de ARIA

ARIA es tentadora porque promete describir cualquier componente, pero en correo depende de lo que cada cliente deje pasar. Según caniemail, aria-label y aria-hidden se conservan en Gmail, Apple Mail y Outlook para Windows y se pierden en Yahoo y AOL. aria-labelledby falla en Gmail (el cliente antepone un prefijo al id, pero no al valor que lo referencia) y en Outlook para Windows, que elimina el id; aria-describedby tiene el mismo problema de prefijo en Gmail. La conclusión práctica es que la estructura debe sostenerse sin ARIA y que, si añades aria-label, nunca debe ser la única etiqueta de un control.

Tamaño, espaciado y movimiento

Escribe los tamaños de letra en px: la ficha de font-size indica que las unidades rem no se admiten en Outlook para Windows ni en Yahoo. El criterio 1.4.12, Espaciado del texto, exige que no se pierda contenido cuando el lector fija el interlineado en al menos 1,5 veces el tamaño de la letra, el espacio tras los párrafos en 2 veces, el espaciado entre letras en 0,12 y entre palabras en 0,16. En la práctica, eso desaconseja las celdas de altura fija con texto dentro. Para el movimiento, prefers-reduced-motion funciona en Apple Mail y Outlook.com, pero no en Gmail; un GIF animado debe tener un primer fotograma que diga lo esencial y nada que parpadee.

Un proceso de revisión que cabe en un cuarto de hora

1. Quien redacta abre la lista de enlaces de un lector de pantalla (o relee todos los textos de enlace fuera de contexto) y reescribe los que no se entienden solos.
2. Quien diseña calcula el contraste de cada pareja de colores de texto y botón, en la paleta clara y en la oscura, y comprueba que el orden de las celdas coincide con el orden de lectura.
3. Quien maqueta exporta el HTML final y busca lang, role="presentation", la secuencia de titulares y todos los alt.
4. Quien aprueba desactiva las imágenes en un cliente real y verifica que la oferta, la fecha y la acción siguen siendo legibles.

Para elegir una herramienta que genere ya parte de este marcado, la guía de constructores de correo HTML compara el enfoque visual y el de código, y MJML frente a React Email detalla lo que hace cada framework con el idioma y las tablas. Para el resto de limitaciones de estilo, consulta la guía de CSS en el correo y la guía de compatibilidad entre clientes.