Accesibilidad: diseñar para todos

La accesibilidad no es una capa que se añade al final. Es una serie de decisiones de diseño que, si se toman desde el principio, cuestan casi nada. Si se ignoran hasta el final, pueden requerir rediseñar componentes enteros.

Un producto accesible no es un producto para “usuarios con discapacidad”. Es un producto que funciona en más contextos: con una sola mano, con pantalla al sol, con conexión lenta, con un teclado y sin ratón, con el tamaño de texto aumentado al 200 %.

WCAG: el estándar de referencia

WCAG (Web Content Accessibility Guidelines) es el estándar internacional de accesibilidad web. Define tres niveles:

• A: criterios mínimos que no deben romperse.
• AA: el nivel exigido por la mayoría de normativas legales (EN 301 549 en Europa, ADA en EEUU). Es el objetivo práctico para la mayoría de productos.
• AAA: el nivel más estricto, difícil de cumplir en todo el producto pero al que se puede aspirar en áreas críticas.

WCAG se organiza en cuatro principios (POUR):

• Perceptible: el contenido debe poder percibirse con independencia del sentido que use el usuario.
• Operable: las funciones deben poder activarse con independencia del dispositivo de entrada.
• Comprensible: el contenido y la navegación deben ser fáciles de entender.
• Robusto: el contenido debe funcionar correctamente con tecnologías de asistencia actuales y futuras.

Lo que más impacto tiene como diseñador

1. Contraste de color

El contraste entre el texto y su fondo debe cumplir:

• Texto normal (hasta 18px regular u 14px bold): ratio mínimo de 4.5:1 (AA).
• Texto grande (18px regular o más, o 14px bold o más): ratio mínimo de 3:1 (AA).
• Componentes e iconos interactivos: ratio mínimo de 3:1 respecto al fondo.

Herramientas:

• Plugin de Figma: Contrast o A11y - Color Contrast Checker.
• Web: webaim.org/resources/contrastchecker.
• Extensión de navegador: Accessibility Insights for Web.

Un gris claro sobre blanco puede parecer sofisticado en un monitor calibrado. En un portátil al sol, es completamente ilegible.

2. Foco visible

Cuando un usuario navega con teclado (Tab, Shift+Tab, flechas), cada elemento interactivo debe mostrar un indicador de foco claramente visible. Eliminar el outline de foco por razones estéticas es una de las decisiones de diseño más dañinas para la accesibilidad.

Criterio AA: el indicador de foco debe tener un área de al menos 3px alrededor del componente y un ratio de contraste mínimo de 3:1 entre el estado foco y el estado sin foco.

Diseña el estado de foco como un estado más del componente, junto con hover, active y disabled. No lo dejes al navegador ni a los desarrolladores.

3. Tamaño de objetivo táctil

Los elementos interactivos deben tener un área de toque mínima de 44×44px (recomendación WCAG 2.5.5 AAA) o al menos 24×24px (criterio AA en WCAG 2.2).

Un botón de 32×16px es un objetivo táctil fallido en móvil. El componente puede ser visualmente más pequeño, pero el área de toque debe ser suficiente.

4. No usar el color como único canal de información

Si el color es el único indicador de un estado (un campo rojo de error, un punto verde de “activo”), los usuarios con daltonismo u otras alteraciones de percepción del color no pueden interpretarlo.

Regla: el color siempre acompaña a otro indicador: un ícono, una etiqueta de texto, un cambio de forma u un patrón.

Ejemplos correctos:

• Campo de error: borde rojo + ícono de alerta + texto de error debajo.
• Estado activo: punto verde + etiqueta “Activo”.
• Gráfico: colores distintos + patrones de relleno distintos.

5. Textos alternativos para imágenes

Toda imagen que transmite información necesita un texto alternativo que describa esa información. Las imágenes decorativas deben tener alt="" para que los lectores de pantalla las ignoren.

Como diseñador, tu responsabilidad es especificar en el handoff qué imágenes son informativas, qué texto alternativo deben tener y cuáles son puramente decorativas.

6. Jerarquía de encabezados

Los encabezados (H1, H2, H3…) no son solo estilos visuales. Son la estructura semántica que los lectores de pantalla usan para navegar el contenido.

Reglas básicas:

• Un solo H1 por página: el título principal.
• Los encabezados no deben saltar de nivel: un H3 debe ir siempre después de un H2, no directamente después de un H1.
• No uses encabezados para conseguir un tamaño de texto determinado: usa estilos de texto normales si no es un encabezado real.

En el handoff, especifica el nivel semántico de cada texto, no solo su estilo visual.

7. Etiquetas en formularios

Todo campo de formulario necesita una etiqueta visible asociada programáticamente. No basta con que visualmente parezca que el texto de encima es la etiqueta: debe estar conectado al campo.

Como diseñador, asegúrate de que el spec incluye el label para cada campo y que no hay campos solo con placeholder.

8. Mensajes de error accesibles

Los mensajes de error deben:

• Ser descritos en texto, no solo en color.
• Estar asociados al campo que los generó (no solo cerca visualmente).
• Ser anunciados por el lector de pantalla cuando aparecen (live region o foco automático).

Herramientas para validar accesibilidad en diseño

Las herramientas automatizadas detectan entre el 30 y el 40 % de los problemas de accesibilidad. El resto solo se detecta con pruebas manuales y con usuarios reales que usan tecnologías de asistencia.

Accesibilidad en el Design System

El lugar correcto para resolver accesibilidad es el Design System, no pantalla a pantalla.

Cada componente debe documentar:

• Requisitos de contraste aplicables.
• Comportamiento con teclado: qué teclas activan qué acciones.
• Atributos ARIA necesarios cuando el HTML semántico no es suficiente.
• Anuncios de lector de pantalla en estados dinámicos (errores, notificaciones, carga).

Si el botón del Design System tiene el foco visible diseñado correctamente, todos los botones del producto lo tienen. Si no lo tiene, ninguno lo tiene.

¿Qué hemos aprendido?

• Accesibilidad es un criterio de diseño, no una capa final de auditoría.
• Los impactos más altos como diseñador están en: contraste, foco, tamaño táctil, color como único canal e información semántica.
• El Design System es el lugar correcto para resolver accesibilidad de forma sistemática.
• Las herramientas automatizadas solo detectan una parte del problema; las pruebas con usuarios reales son imprescindibles.

Siguiente paso

En la próxima lección veremos Handoff con desarrollo: cómo preparar los entregables de Figma para que el equipo de desarrollo pueda implementar sin adivinar.