Estimación de una solución para la accesibilidad
Cómo estimar una corrección de accesibilidad: los problemas de accesibilidad son funcionalidades que no se incluyeron en la primera versión. Por qué hay que evaluar la magnitud del problema en su conjunto, y no cada caso concreto.
Las correcciones de accesibilidad no son errores. Son funciones que el equipo no incluyó en la primera versión.
Tratar un problema de accesibilidad como si fuera un error («corrija la ventana modal para que retenga el foco») limita la solución a ese problema concreto. No tiene en cuenta aquello de lo que depende dicha solución: el resto del proceso de navegación mediante teclado, los mensajes del lector de pantalla y el contraste de colores, que probablemente presente el mismo problema en la siguiente ventana modal. La mayoría de las «pequeñas correcciones de accesibilidad» son puntos de entrada a una clase de problemas que se extiende por todo el componente.
La estimación realista se refiere a la clase, no a la instancia. Si implementa una corrección, tendrá que volver en el siguiente sprint para la clase hermana, y para la hermana de esta, hasta que alguien admita que el trabajo consiste en «auditar el modelo de interacción modal» y lo evalúe en consecuencia.
Lo que se dice en la sala
Frontend: «Añadir la trampa de foco lleva medio día».
Pregunta de control de calidad: «¿Se anuncia el botón de cerrar en los lectores de pantalla?»
Diseñador: «¿Es adecuado el contraste del botón secundario?»
Pregunta inicial: «¿Cuántos otros verbos modales tienen la misma forma?»
PM: «¿Vamos a revisarlos todos o solo el que ha sido objeto de quejas por parte de los clientes?»
Preguntas que conviene plantearse antes de votar
- ¿Se trata de una instancia o de una clase? ¿Cuántos componentes similares existen?
- Ámbito de la auditoría: ¿este componente, esta página, este producto?
- Nivel de cumplimiento de las WCAG: ¿A, AA, AAA?
- Pruebas: ¿Axe, lector de pantalla manual, guía paso a paso solo con teclado?
- Prevención de regresiones: ¿regla de Lint, instantánea de la historia, comprobación de CI?
- ¿Cuál será el presupuesto previsto para las tareas de accesibilidad una vez que se haya puesto en marcha este proyecto?
Si se trata de una clase y no de una instancia, separe el componente al que acceden los clientes de la auditoría del resto, y evalúe cada uno en función de lo que realmente se haya comprometido a hacer.
Determine el tamaño de la clase, no de la instancia. Una «trampa de enfoque» es medio día; el patrón que hay detrás es la historia.
Al igual que al estimar un cambio en un sistema de diseño, la corrección en la fase inicial es mínima y la cobertura en las fases posteriores constituye el trabajo propiamente dicho. Consulte los demás ejemplos de estimación resueltos o inicie una sesión gratuita de «planning poker» una vez que se haya acordado el alcance.