Inicio / Guías / Plantillas de email accesibles: alt, contraste, tipografía y tap targets

Crear plantillas de email accesibles: alt, contraste, tipografía y tap targets

4,6 · 45 valoraciones
· Actualizado el 3 de enero de 2026

Guía técnica para crear plantillas de email accesibles: alt text útil, contraste WCAG, tamaño de fuente mínimo en móvil, tap targets y estructura semántica.

Plantillas de email accesibles: alt, contraste, tipografía y tap targets
Forma parte de Deliverability

La accesibilidad en email no es solo cumplimiento normativo. Una plantilla accesible se entiende mejor con imágenes bloqueadas, funciona en clientes antiguos, lee correctamente con VoiceOver y se renderiza más rápido. El resultado: más engagement real, menos fricción y mejor reputación. Este es el conjunto de prácticas técnicas que debe cumplir cualquier plantilla profesional.

Por qué importa la accesibilidad en email

Los filtros antispam no miden directamente la accesibilidad, pero sí evalúan señales que se solapan con ella: ratio texto/HTML razonable, presencia de alt en imágenes, ausencia de imágenes con texto incrustado y estructura semántica. Una plantilla accesible cumple todas estas señales de forma natural.

A nivel de usuario, el email accesible suma:

  • Lectura más rápida en clientes que bloquean imágenes por defecto (Outlook desktop, algunas configuraciones de Gmail).
  • Menor tasa de archivado o borrado por contenido ilegible.
  • Mejor experiencia con texto pequeño en móvil.
  • Cumplimiento WCAG, requisito en muchos sectores regulados.

Y a nivel de marca, refleja cuidado: las plantillas con texto incrustado en imágenes y contraste pobre transmiten descuido tanto como dañan métricas.

Estructura semántica básica

El email tiene su propia mezcla de HTML antiguo (tablas para layout) y técnicas modernas. La estructura semántica se respeta donde se puede.

Tablas de layout marcadas como presentacionales

Como las tablas en email se usan para layout, no para datos, conviene marcarlas:

<table role="presentation" cellpadding="0" cellspacing="0" border="0">

Así los lectores de pantalla no las anuncian como “tabla con N filas y M columnas”.

Lang en el html

El atributo lang en <html> ayuda a que el lector de pantalla use la pronunciación correcta:

<html lang="es">

Encabezados jerárquicos

Aunque sea un email, conviene usar <h1>, <h2>, <h3> con jerarquía clara. Los lectores de pantalla permiten saltar de encabezado a encabezado, lo que ayuda a usuarios con baja visión a explorar el contenido. Solo un <h1> por email, normalmente el título principal.

Listas reales

Si tienes una lista, usa <ul> o <ol>. No simules listas con asteriscos o emojis: el lector las leerá como párrafo continuo.

Contraste de color

WCAG 2.1 nivel AA pide:

  • 4.5:1 para texto normal.
  • 3:1 para texto grande (18pt o 14pt en negrita).
  • 3:1 para componentes UI y gráficos esenciales.

Combinaciones habituales que suelen fallar:

  • Gris medio (#999) sobre blanco: 2.85:1, no cumple.
  • Azul corporativo claro (#4a9bf0) sobre blanco: 3.0:1, solo cumple para texto grande.
  • Texto negro sobre fondo de marca saturado: revisar caso a caso.

Validar contraste no es opcional. Cualquier pareja que aparezca en la plantilla debe pasar el comprobador. Y conviene revisar tanto la versión light como la dark, como se trata en la guía de HTML email en dark mode.

Tipografía y tamaño de fuente

El tamaño mínimo razonable es:

  • Cuerpo en desktop: 14-16px.
  • Cuerpo en móvil: 16-18px.
  • Texto secundario y disclaimers: 12-14px nunca menos.
  • Encabezados: 22-32px en función del nivel.

En móvil, iOS aumenta automáticamente el tamaño de fuentes pequeñas para evitar el zoom forzado. Eso puede romper el layout si la plantilla no lo prevé. La solución es declarar tamaños suficientes desde el inicio:

<style>
  body, table, td, p { font-size: 16px; line-height: 1.5; }
  @media only screen and (max-width: 480px) {
    body, table, td, p { font-size: 17px !important; }
  }
</style>

line-height de 1.4 a 1.6 mejora la lectura y evita que el texto quede demasiado apretado.

Fuentes web

Algunos clientes (Apple Mail, iOS Mail, Outlook macOS) cargan fuentes web vía @import o @font-face. Otros (Gmail web, Outlook desktop Windows) las ignoran. Lo razonable es:

  • Definir una fuente web preferida.
  • Tener un fallback de stack tipográfico claro: 'Inter', -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Arial, sans-serif.
  • No depender de la fuente web para que el diseño funcione.

Alt text útil

El alt text es el texto que aparece cuando la imagen no se carga o cuando un lector de pantalla la describe. Hay tres reglas básicas.

Imágenes informativas

Si la imagen aporta contenido (un gráfico, un producto, una persona identificable), describe lo relevante. No pongas “imagen de” o “foto de”: el lector ya sabe que es una imagen.

<img src="producto.jpg" alt="Auriculares Bluetooth en color negro mate">

Imágenes decorativas

Si la imagen es solo decorativa (un patrón de fondo, un divisor visual), usa alt="" para que el lector de pantalla la ignore.

<img src="separador.png" alt="" role="presentation">

Logos y CTAs

El logo lleva el nombre de la marca como alt. Si la imagen es un botón, el alt describe la acción, no la imagen:

<img src="cta.png" alt="Comprar ahora">

Mejor todavía: construye los CTAs como botones HTML, no como imágenes, así no dependes del alt.

Imágenes con texto: evitar

Los filtros antispam penalizan la práctica de incrustar texto en imágenes. Y los usuarios con imágenes bloqueadas se quedan sin contenido. Las dos reglas:

  • Texto importante: siempre en HTML.
  • Imágenes: solo apoyo visual, productos, personas, escenarios.

Si necesitas un titular gráfico, hazlo en HTML con tipografía de marca. Si necesitas una imagen con varias líneas de texto, el lector de pantalla no podrá leerlas y los filtros bajarán la confianza.

Tap targets en móvil

Apple recomienda 44x44 puntos. Google recomienda 48x48 dp. En email, esto se traduce en:

  • Botones de al menos 44 píxeles de alto, con padding interno generoso (12-16px arriba y abajo, 24-32px a los lados).
  • Separación de al menos 12 píxeles entre enlaces clicables consecutivos.
  • Enlaces de texto en bloques no muy juntos (line-height >= 1.5 ayuda).

El típico bloque de “redes sociales” en el footer suele incumplir esto: cinco iconos pegados de 24x24. Conviene rediseñarlos con más separación.

<table role="presentation"><tr>
  <td style="padding: 0 12px;"><a href="..." style="display:inline-block;width:44px;height:44px;"><img src="ig.png" alt="Instagram" width="24" height="24"></a></td>
  <td style="padding: 0 12px;"><a href="..." style="display:inline-block;width:44px;height:44px;"><img src="x.png" alt="X" width="24" height="24"></a></td>
</tr></table>

El icono visual sigue siendo de 24px, pero el área tocable es de 44x44 gracias al display:inline-block con dimensiones forzadas.

Botones HTML accesibles

Un botón accesible es un enlace estilizado con suficiente padding, color de fondo claro y texto que describe la acción.

<a href="https://..."
   style="display:inline-block;
          background:#0a66c2;
          color:#ffffff;
          padding:14px 28px;
          font-size:16px;
          font-weight:600;
          text-decoration:none;
          border-radius:6px;">
  Ver mi pedido
</a>

Tres comprobaciones:

  • Contraste texto-fondo: 4.5:1 mínimo.
  • Padding suficiente: 14-16px en vertical, 24-32px en horizontal.
  • Texto descriptivo: “Ver mi pedido” es mejor que “Aquí” o “Click”.

Estructura del email para lectores de pantalla

Un lector de pantalla lee el email de arriba abajo, atravesando todo el HTML. Algunas claves:

Preheader oculto

El preheader es la primera línea que se ve junto al asunto en la bandeja. Suele incluirse oculto en el HTML para no aparecer dos veces. Marcarlo correctamente evita que el lector lo lea como ruido:

<div style="display:none;max-height:0;overflow:hidden;mso-hide:all;">
  Resumen breve del contenido del email para mostrar como preview.
</div>

Skip-to-content

En emails muy largos, un enlace inicial “Saltar al contenido” ayuda a usuarios de lectores de pantalla a no escuchar el header completo cada vez.

Elementos aria-hidden

Iconos decorativos junto a un texto repiten información si no se ocultan al lector. aria-hidden="true" los excluye de la lectura.

Versión texto plano (multipart)

Todo email debe enviarse como multipart/alternative con una versión text/plain y otra text/html. La versión texto plano:

  • Es la que algunos lectores muestran por defecto.
  • Es la que ciertos filtros analizan para decidir si el email es legítimo.
  • Es accesible por naturaleza.

No vale con generarla automáticamente eliminando etiquetas: revisa que tenga los enlaces principales en formato URL y el contenido en orden lógico.

Errores frecuentes

Texto en imágenes

Mata accesibilidad y deliverability a la vez.

Botones como <button> o <input>

Muchos clientes (Outlook, Gmail) no renderizan estos elementos correctamente en email. Usa enlaces con estilos.

Color como única señal

“Pulsa el enlace en rojo” es inaccesible. Suma un texto explícito o un símbolo además del color.

Falta de alt en CTAs gráficos

Si decides usar imágenes como botón, el alt es lo único que tiene un usuario con imágenes bloqueadas. Sin alt, no hay CTA.

Tablas con display: none en móvil

A veces se ocultan elementos en móvil con display:none. Algunos clientes ignoran esa regla. Mejor usar mso-hide:all y max-height:0 combinados.

Disclaimers a 9-10px son ilegibles en móvil. Súbelos a 12-13px y respeta los enlaces de baja con tap target adecuado, sobre todo en el List-Unsubscribe visible.

Cómo integrarlo en el flujo

Convertir la accesibilidad en un control sistemático evita que se diluya con la urgencia. Algunas prácticas:

  • Plantilla base con tokens de tipografía, paleta y espaciado ya validados.
  • Checklist de accesibilidad en la revisión previa a cada envío.
  • Auditoría con lector de pantalla cada trimestre o tras cambios mayores.
  • Comprobación de contraste automática en CI si el HTML se genera desde un sistema propio.

La accesibilidad cuesta poco si está integrada desde el inicio. El coste real aparece cuando hay que rehacer plantillas heredadas con texto incrustado y contraste pobre. Empezar bien es la mejor inversión.

Recursos relacionados

Si quieres profundizar, prueba estas herramientas gratuitas: Domain Health, mail tester, validador SPF y validador DMARC.

¿Necesitas que alguien lleve tu canal de email entero? Abalola Mail es la agencia de email marketing para ecommerce de Abalola para ecommerce: estrategia, producción y operación del stack sobre Klaviyo, Mailchimp o Brevo.

Preguntas frecuentes

¿La accesibilidad afecta a la deliverability?
Indirectamente sí. Plantillas accesibles tienen mejor ratio texto/imagen, no abusan de imágenes con texto y aportan estructura semántica que los filtros valoran como señal de remitente legítimo. Además, la accesibilidad mejora engagement, que es señal de reputación.
¿Qué tamaño mínimo de fuente debo usar?
Para el cuerpo del mensaje, 14px en desktop y 16px en móvil son el mínimo razonable. Bajar de 12px obliga a hacer zoom y dispara los archivados o eliminaciones, que son señales negativas para engagement.
¿Cómo escribir un buen alt text?
Describe la función o el contenido informativo de la imagen, no su aspecto. Si la imagen es decorativa, deja `alt=""` para que los lectores de pantalla la ignoren. Evita repetir el texto que ya está al lado.
¿Qué tap target mínimo se recomienda en móvil?
Apple recomienda 44x44pt y Google 48x48dp. En email, eso se traduce en botones de al menos 44 píxeles de alto y un padding generoso entre enlaces para evitar pulsaciones erróneas.
¿Sirve role="presentation" en las tablas de email?
Sí. Como las tablas se usan para layout, no para datos, marcarlas con `role="presentation"` evita que los lectores de pantalla las anuncien como tablas y mejora la experiencia.