Shift-left: requisitos y diseño accesibles desde el inicio

Shift-left («desplazar a la izquierda») significa mover las actividades de calidad hacia las fases tempranas del ciclo de vida, donde corregir es barato. Aplicado a la accesibilidad, quiere decir que un problema de contraste se resuelve en la paleta, no en producción; que un formulario se diseña con etiquetas visibles antes de que exista una línea de código; y que una historia de usuario no se da por terminada sin sus criterios de aceptación de accesibilidad. En esta lección verás cómo introducir la accesibilidad en requisitos y diseño con plantillas y una revisión de diseño que funcione.

Por qué a la izquierda

El coste de corregir un defecto crece de forma muy marcada según la fase en que se detecta. Un botón con texto gris claro sobre fondo blanco se arregla en el archivo de diseño en dos minutos; en producción exige abrir incidencia, priorizar, modificar código, probar, desplegar y, a menudo, discutir con marketing sobre la identidad corporativa. Multiplica eso por cientos de componentes y entenderás por qué las organizaciones que solo auditan al final nunca alcanzan la conformidad: cada versión nueva introduce fallos más rápido de lo que se corrigen los anteriores.

Shift-left no elimina la auditoría final; la convierte en una confirmación en lugar de un descubrimiento.

Accesibilidad en los requisitos

Requisitos no funcionales del producto

Todo producto digital debería tener, en su documento de requisitos o en su definición inicial, una cláusula de accesibilidad con el nivel exigido (WCAG 2.2 AA; EN 301 549 (PDF, se abre en una ventana nueva) para software, documentos y apps), las tecnologías de apoyo con las que se probará (por ejemplo, NVDA con Firefox y Chrome, VoiceOver en Safari e iOS, TalkBack en Android), los navegadores y tamaños de ventana soportados, y cómo se verificará antes de cada entrega.

Historias de usuario con criterios de aceptación

En equipos ágiles, la unidad de trabajo es la historia de usuario. La forma más eficaz de integrar la accesibilidad es doble: criterios de aceptación específicos en cada historia y una definición de hecho (definition of done) común con comprobaciones de accesibilidad que aplican siempre.

Observa que los criterios se expresan como comportamientos observables («se puede usar con teclado», «se anuncia»), no como «cumple WCAG». Eso permite a QA verificarlos y a desarrollo saber qué construir.

Plantilla de definición de hecho (fragmento de accesibilidad)

• Pasa las pruebas automáticas de axe-core sin violaciones en los estados principales del componente o pantalla.
• Toda la funcionalidad se opera con teclado; el foco es visible y sigue un orden lógico.
• Probado con un lector de pantalla de escritorio en los flujos que incluye la historia.
• Contrastes de texto y componentes verificados con los tokens del design system.
• Funciona con zoom del 200 % y en ventana de 320 píxeles CSS de ancho sin pérdida de contenido (1.4.4 Cambio de tamaño del texto, 1.4.10 Reajuste de los elementos).
• Sin contenido que dependa solo del color, del movimiento o de un gesto complejo.
• Si introduce contenido, tiene textos alternativos, encabezados y, en vídeo, subtítulos.

Accesibilidad en el diseño

El diseño fija decenas de decisiones que después nadie reconsidera: colores, tamaños, espaciados, orden visual, estados de los componentes, textos de etiquetas y de error. Dos prácticas convierten el diseño en aliado:

Anotaciones de accesibilidad en los archivos de diseño

Cada pantalla entregada a desarrollo debería llevar anotaciones de: orden de foco (números sobre los elementos interactivos), encabezados y su nivel, landmarks (regiones: cabecera, navegación, principal, pie), nombre accesible de iconos y botones sin texto, comportamiento con teclado de los componentes complejos, textos alternativos de imágenes, y qué ocurre con el foco al abrir y cerrar diálogos. Existen kits de anotación para herramientas como Figma que facilitan el trabajo; lo importante es que la convención sea única en la organización.

Revisión de diseño (design review) con lista de comprobación

Antes de pasar a desarrollo, una persona con formación revisa cada pantalla con una lista fija. Una lista de 12 puntos es suficiente para detectar la mayoría de los problemas de diseño:

1. Contraste de texto normal ≥ 4,5:1 y de texto grande ≥ 3:1 (1.4.3 Contraste (mínimo)).
2. Contraste de bordes de campos, iconos informativos y estados ≥ 3:1 (1.4.11 Contraste no textual).
3. Ninguna información transmitida solo por color (1.4.1 Uso del color).
4. Objetivos táctiles de al menos 24 × 24 píxeles CSS, preferiblemente 44 × 44 (2.5.8 Tamaño del objetivo (mínimo)).
5. Estado de foco diseñado para cada componente interactivo y visible sobre todos los fondos (2.4.7 Foco visible).
6. Etiquetas visibles en todos los campos; el placeholder no sustituye a la etiqueta (3.3.2).
7. Mensajes de error diseñados: dónde aparecen, qué dicen, cómo se relacionan con el campo (3.3.1, 3.3.3).
8. Jerarquía de encabezados coherente con la estructura visual (1.3.1, 2.4.6 Encabezados y etiquetas).
9. Orden de lectura y de foco definido, especialmente en diseños de varias columnas (1.3.2 Secuencia significativa, 2.4.3 Orden del foco).
10. Comportamiento en 320 píxeles de ancho y con texto al 200 % (1.4.10, 1.4.4).
11. Sin autoplay de audio ni animaciones no desactivables de más de 5 segundos (1.4.2, 2.2.2 Poner en pausa, detener, ocultar).
12. Funciones que requieran arrastrar tienen alternativa de un solo puntero (2.5.7 Movimientos de arrastre).

Cómo introducirlo en un equipo que no lo hace

Si el equipo no tiene la práctica, no impongas la lista completa de golpe. Un camino que funciona: empezar con la definición de hecho (tres comprobaciones: axe, teclado, zoom); a las pocas semanas, añadir la revisión de diseño en las pantallas nuevas; después, los criterios de aceptación específicos en las historias de formularios y flujos críticos; por último, las anotaciones completas. Mide en cada paso cuántos defectos de accesibilidad llegan a producción: la cifra debe caer y es el mejor argumento para seguir.

Resumen

• Shift-left mueve la accesibilidad a requisitos y diseño, donde corregir cuesta una fracción de lo que cuesta en producción.
• Cada historia de usuario lleva criterios de aceptación de accesibilidad observables; la definición de hecho común añade comprobaciones que aplican siempre.
• El diseño se entrega con anotaciones (orden de foco, encabezados, regiones, nombres accesibles, estados) y pasa una revisión con lista de comprobación de 12 puntos.
• Diseñar todos los estados (foco, error, carga, vacío) evita que se improvisen en desarrollo.