Estimación de una solución para la accesibilidad

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 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 por 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 ocuparse de la siguiente, y de la siguiente de esa, 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 enfoque 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 principal: «¿Cuántos otros verbos modales tienen la misma forma?»

PM: «¿Las revisamos todas o solo aquella de la que se han quejado 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 el trabajo 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 de la auditoría, y compare el tamaño de cada uno con lo que realmente se ha comprometido a ofrecer.

Analice la clase, no la instancia. Una trampa en la que es fácil caer 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 reside en la cobertura de las fases posteriores. Consulte los demás ejemplos prácticos de estimación, o organice una sesión gratuita de «planning poker» una vez que se haya acordado el alcance.