Revisión de accesibilidad en el proceso de diseño: cuándo, quién y cómo

La revisión de accesibilidad ocurre en cada etapa, no solo al final. Qué se revisa en requisitos, diseño, desarrollo y QA, y cómo llevarla al sprint.

info Definición Rápida
Una revisión de accesibilidad en el proceso de diseño es la comprobación repetida, en cada etapa del trabajo, de que las pantallas, componentes y flujos cumplen los criterios de accesibilidad definidos, normalmente WCAG 2.2 nivel AA (la versión más reciente de WCAG según el W3C). Su objetivo es encontrar los problemas cuando cuestan minutos y no semanas.

¿Qué significa revisar accesibilidad en cada etapa?

La idea se conoce como shift left: mover la comprobación hacia el principio. Digital A11y propone pensar en accesibilidad desde el inicio y revisar los diseños mientras son bocetos, wireframes o maquetas. Según el mismo artículo, identificar y corregir los problemas en una etapa tardía es mucho más caro (Digital A11y, «Shift Left Accessibility in Design, Development and Testing»).

Ejemplo ilustrativo con el contraste: corregir un gris en Figma puede llevar minutos; corregirlo después en veinte componentes que ya están en código, con sus pruebas y su despliegue, puede llevar días. Lo mismo pasa con el orden de foco o con los nombres de los controles, que dependen de decisiones de estructura.

¿Qué se revisa en cada etapa?

Una secuencia posible:

  1. Planificación. Se fijan objetivos y una política de accesibilidad, se asignan responsabilidades y se reservan presupuesto y recursos. Así lo describe la fase «Plan» del W3C (W3C WAI, «Planning and Managing Web Accessibility»).
  2. Requisitos. Cada historia de usuario incluye criterios de aceptación de accesibilidad. EZUD propone escribir criterios de aceptación de accesibilidad en cada historia, relacionar las funciones con los criterios de WCAG 2.2 en el refinamiento e incluir el esfuerzo de accesibilidad en la estimación (EZUD, «Shift-left accessibility»).
  3. Diseño. Una revisión en cada hito, sobre bocetos, wireframes y maquetas. Digital A11y propone revisar la estructura semántica, la tipografía y el espaciado, los indicadores de foco, el contraste de color y el texto de los enlaces, y anotar los diseños.
  4. Prototipo y pruebas con personas. Cuando el prototipo lo permite, pruebas con personas con discapacidad. El W3C recomienda involucrarlas durante todo el proceso. Revisa también los estados fuera del camino feliz.
  5. Desarrollo y QA. Pruebas automatizadas y manuales: teclado, lector de pantalla, contraste, formularios. EZUD menciona herramientas de análisis estático que detectan problemas antes de la revisión de código. Los hallazgos se registran como defectos y vuelven al equipo.
  6. Antes de publicar. Una auditoría completa contra el nivel objetivo, que confirme lo revisado en las etapas anteriores. La guía del W3C pide además evaluar «temprano y con regularidad», no solo al final.

¿Quién hace qué?

El W3C publica un recurso borrador, el ARRM (Accessibility Roles and Responsibilities Mapping), que pide asignar las responsabilidades de accesibilidad a los roles desde el inicio del proyecto y las marca como primarias, secundarias o de contribución; sus roles de ejemplo son diseñador de UX, diseñador visual, autor de contenido y desarrollador front-end (W3C WAI, ARRM). Un reparto habitual en un equipo de producto, que puedes adaptar:

  • Diseño. Anota y revisa las pantallas: contraste, tamaño de texto, estilos de foco, orden de lectura, estados y espaciado. Conviene formarse en WCAG, porque muchas decisiones de color y de jerarquía son de diseño.
  • Desarrollo. Garantiza el HTML semántico, el uso correcto de ARIA y la navegación con teclado. La revisión de código puede incluir una lista de comprobación de accesibilidad.
  • QA. Ejecuta las pruebas automatizadas y las manuales, y registra los hallazgos con pasos para reproducirlos. Las pruebas con lectores de pantalla son parte de su trabajo, y muchas veces necesitan la ayuda de diseño para interpretar lo que ocurre.
  • Especialista. Audita contra WCAG 2.2 AA, evalúa las correcciones y enseña al equipo. Puede ser interno o externo.

¿Cómo entra en el sprint?

La accesibilidad no es una tarea paralela. EZUD lo dice sin rodeos: no es opcional y no está separada de la definición de hecho. Eso significa que una historia no se cierra si no cumple sus criterios de accesibilidad, igual que no se cierra si falla su lógica.

En la práctica, esto implica tres cosas: criterios de aceptación escritos en cada historia, comprobaciones dentro del sprint y hallazgos que se priorizan como cualquier otro defecto. Una regla práctica: lo que impide completar una tarea se corrige antes de publicar; el resto entra al backlog con prioridad.

Ejemplo

Ejemplo ilustrativo: un equipo añade un flujo de pago. En el refinamiento, la historia incluye criterios de accesibilidad: el formulario se completa solo con teclado, los errores se anuncian al lector de pantalla y el botón de pagar tiene nombre accesible. En el diseño, la revisión de hito detecta que el error aparece solo en color rojo y que el orden de foco salta del campo de tarjeta al botón de cancelar. Se corrige antes de codificar. En QA, la prueba con lector de pantalla revela que el aviso de error no se anuncia porque la región se crea después del mensaje. El desarrollador ajusta la región y la prueba se repite. Ninguna de esas correcciones obligó a rehacer el flujo.

¿Cuándo NO basta esta revisión?

  • Cuando solo se usan herramientas automáticas. Detectan una parte de los problemas. Las pruebas manuales son necesarias para orden de lectura, nombres significativos y anuncios.
  • Cuando la revisión llega solo al final. Una auditoría de última hora encuentra problemas de estructura que ya están en el código.
  • Cuando el equipo no tiene a nadie responsable. Sin un dueño, cada disciplina asume que la otra lo hace.
  • Cuando se usa como sello de cumplimiento. Un informe sin correcciones no hace accesible un producto.

Errores comunes

  • Dejar la accesibilidad para la última semana antes del lanzamiento.
  • Revisar solo el contraste y olvidar el orden de foco y los estados.
  • Probar solo con el teclado y no con un lector de pantalla.
  • No registrar los hallazgos como defectos con su prioridad.
  • Confiar en un score automático como medida de cumplimiento.

Cómo empezar mañana

Elige una historia de tu backlog que esté en diseño. Añade tres criterios de aceptación de accesibilidad: uso con teclado, nombres accesibles y mensajes de error anunciados. Revisa el diseño con esos tres criterios antes de pasarlo a desarrollo, con axe DevTools para la versión construida y Stark para la paleta. Para anotar los diseños, mira las anotaciones de accesibilidad. Si el proceso de colaboración con desarrollo ya incluye una lista de preguntas, añade estas tres. Y para la parte manual, la prueba con lectores de pantalla es el siguiente paso.

Fuentes

Preguntas frecuentes

¿Cuándo debe hacerse una revisión de accesibilidad?
En cada etapa: al definir requisitos con criterios de aceptación, en cada hito de diseño, durante el desarrollo y en QA. Esperar a una auditoría final encarece las correcciones y suele dejar problemas de estructura que son caros de cambiar.
¿Quién hace la revisión de accesibilidad?
Cada disciplina tiene su parte. Un reparto habitual: diseño revisa contraste, orden de foco, estados y espaciado; desarrollo revisa HTML semántico, ARIA y teclado; QA prueba con lectores de pantalla y tecnologías de apoyo. Un especialista interno o externo puede auditar contra WCAG 2.2 AA.
¿Cómo se integra la accesibilidad en un sprint?
Como parte de la definición de hecho y de los criterios de aceptación de cada historia, no como una tarea aparte. EZUD lo resume así: no es opcional y no está separada de la definición de hecho.
¿Basta con una herramienta automática?
No. Digital A11y señala que, si solo haces pruebas automáticas, se te escaparán problemas: hacen falta también pruebas manuales y, cuando es posible, pruebas con personas con discapacidad. El teclado y el lector de pantalla sirven para validar nombres, orden de lectura, anuncios y flujos.