El correo en HTML sigue siendo HTML, renderizado por un agente de usuario — un cliente de webmail es un navegador, y el motor de renderizado de una app de correo nativa no es fundamentalmente distinto. Los criterios de éxito de WCAG no contemplan una excepción específica para el correo, y se aplican de forma tan directa a una encuesta, un cuestionario o un acordeón basados únicamente en CSS como al componente web equivalente. Esta es una lista de verificación práctica para los cuatro criterios más relevantes en el correo interactivo impulsado por la técnica del checkbox oculto.
Por qué WCAG se aplica aquí
WCAG 2.2 está redactado en términos de "contenido" renderizado por un "agente de usuario", no de "páginas web" específicamente — no es un estándar formal específico para el correo, ya que el correo como medio no se menciona en absoluto en la especificación, pero el contenido subyacente es HTML de todas formas. Por eso la comunidad de accesibilidad trata los criterios de éxito de WCAG como el estándar práctico para el contenido de correo, de la misma forma que hace esta lista de verificación, en lugar de tratar el correo como una categoría separada a la que las pautas no llegan.
1.1.1 Contenido no textual — cada imagen necesita un alt real
Las fotos de producto, las imágenes de cabecera, los separadores decorativos y los botones solo de icono necesitan todos un atributo alt que un lector de pantalla pueda anunciar — o, para imágenes genuinamente decorativas que no aportan información, un alt="" explícitamente vacío para que el lector de pantalla las omita en lugar de leer un nombre de archivo sin sentido. Esto importa más en los bloques interactivos que en los estáticos: una ruleta de gira y gana o una tarjeta de rascar y revelar totalmente basadas en imágenes, sin una alternativa textual que describa el resultado, deja a un usuario de lector de pantalla sin forma de saber qué ha ganado.
1.4.3 / 1.4.11 — Contraste para texto y controles interactivos
WCAG establece un ratio de contraste mínimo de 4.5:1 para el texto de cuerpo normal (3:1 para texto grande, según 1.4.3), y un mínimo de 3:1 para los límites visuales de los componentes de interfaz y los gráficos (1.4.11). Ambos se aplican directamente a los elementos interactivos, no solo al texto de párrafo — el borde de una opción de encuesta, el fondo del botón de una respuesta de cuestionario frente a su contenedor, los dígitos de un temporizador de cuenta regresiva frente a su fondo. Un control interactivo con bajo contraste no es solo un fallo estético; puede hacer que el control resulte completamente invisible para un destinatario con baja visión.
2.1.1 Teclado — la ventaja genuina de la técnica del checkbox oculto
Un <input type="radio">/<input type="checkbox"> real emparejado con un <label for="..."> es de forma nativa enfocable y operable con Tab más Espacio o Intro, en cualquier cliente que renderice controles de formulario en absoluto — sin marcado adicional, sin trabajo extra, porque así es como los navegadores han tratado siempre los controles de formulario reales. Consulta Máquinas de estados CSS con :checked para saber cómo funciona la técnica en sí. Esta es una ventaja genuina frente a lo que suele hacer un carrusel web impulsado por JavaScript — un <div onclick> sin manejador de teclado — y es una ventaja que el correo interactivo obtiene por construcción, no por esfuerzo adicional, siempre que se usen pares reales de <label>/<input> en lugar de simples <div> clicables.
2.5.8 Tamaño del objetivo (mínimo) — nuevo en WCAG 2.2
El criterio de éxito 2.5.8, introducido en WCAG 2.2, establece un mínimo de 24×24 píxeles CSS para los objetivos interactivos, con excepciones para texto en línea, restricciones de diseño esenciales o un control equivalente más grande disponible en otro lugar. Es más relevante en móvil — donde ocurre la mayoría de las aperturas de correo — para los elementos interactivos más pequeños que un estudio facilita encoger demasiado: los puntos de un carrusel, los iconos de valoración por estrellas, las opciones de respuesta de un cuestionario agrupadas muy juntas.
4.1.2 Nombre, rol, valor — etiquetar correctamente los controles :checked
Un lector de pantalla anuncia el nombre, el rol y el estado actual de un control a partir de marcado semántico real — que es exactamente lo que proporciona gratis un <label> que envuelve un <input> real, y exactamente lo que falta en un <div> con estilo desnudo que hace las veces de botón. En la práctica, esto significa que cada opción de encuesta, respuesta de cuestionario y encabezado de acordeón necesita un texto de etiqueta real que un lector de pantalla pueda leer en voz alta, no solo una imagen de fondo o un icono sin texto que lo acompañe.
Lista de verificación práctica
- Cada imagen lleva un
altreal, o unalt=""explícitamente vacío si es decorativa. - El texto y los bordes de los controles interactivos cumplen un contraste de 4.5:1 (texto) / 3:1 (componente de interfaz).
- Cada interacción
:checkedusa un par real de<input>+<label for="...">— nunca un<div>clicable desnudo. - Los objetivos interactivos miden al menos 24×24 píxeles CSS, especialmente en bloques orientados a móvil.
- Las etiquetas de encuestas, cuestionarios y acordeones llevan texto real y legible — no solo una imagen o un icono.