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 el alcance de la solución. 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 se 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 o AAA?
- Pruebas: ¿Axe, lector de pantalla manual, guía paso a paso solo con el 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, utilice la función split para separar el componente al que acceden los clientes del resto —y compare el tamaño de cada uno con lo que realmente se ha comprometido a ofrecer.
Determine el tamaño de la clase, no de la instancia. Una «trampa de atención» es medio día; el patrón que hay detrás es la historia.
Al igual que la estimación de un cambio en el sistema de diseño, la corrección en la fase inicial es mínima y el trabajo real consiste en la cobertura en las fases posteriores. Consulte los demás ejemplos prácticos de estimación, o inicie una sesión gratuita de «planning poker» una vez que se haya acordado el alcance.