Lección 7 de 7 · 12 min
Reportar y priorizar accesibilidad
Al terminar sabrás
12 min- Escribir un reporte de accesibilidad con criterio, impacto y evidencia
- Priorizar por quién queda bloqueado y en qué flujo
- Explicar por qué un widget superpuesto no hace accesible un sitio
Construyes: El informe de accesibilidad de tus tres flujos críticos, priorizado, listo para el equipo.
Un reporte que se arregla
Un bug de accesibilidad mal reportado se queda en el backlog para siempre, porque suena a opinión: "el sitio no es accesible". Un buen reporte lleva seis cosas:
- Qué pasa, en una frase: "El menú Productos no se abre con teclado".
- El criterio WCAG y su nivel: "2.1.1 Teclado, nivel A".
- Quién queda afuera: "Cualquier persona que no usa mouse, incluidas las que usan lector de pantalla".
- Pasos: "Desde la portada, presionar Tab hasta el menú Productos; presionar Enter y Espacio".
- Evidencia: una captura o un video con el foco visible, o lo que anuncia el lector de pantalla.
- Lo esperado: "El menú se abre con Enter o Espacio y se recorre con las flechas".
Con el criterio, la discusión deja de ser de gustos. Con "quién queda afuera", se entiende por qué importa.
Priorizar por bloqueo
No todos los problemas pesan igual. Una forma simple de ordenarlos:
| Prioridad | Qué es | Ejemplo |
|---|---|---|
| Crítica | Bloqueo total en un flujo crítico | No se puede pagar con teclado |
| Alta | Bloqueo en un flujo secundario, o un camino muy difícil en uno crítico | El error del formulario no se anuncia y no dice qué campo falló |
| Media | Dificulta, pero hay un camino alternativo | Contraste bajo en textos de ayuda |
| Baja | Molesta, pero no impide | Un título decorativo mal marcado |
La pregunta guía es la misma de cualquier bug: ¿alguien no puede hacer lo que vino a hacer?
Los widgets superpuestos no son la solución
Es común que una empresa, apurada por cumplir, considere instalar un widget que se superpone al sitio y promete hacerlo accesible con un botón. QA tiene que poder explicar por qué no reemplaza arreglar el código: las personas con discapacidad usan sus propias tecnologías de asistencia (su lector de pantalla, su teclado, su configuración de zoom). Un widget encima no le pone nombre a un botón que no lo tiene ni hace que un menú funcione con teclado. Los problemas siguen en el código.
Que lo arreglado no vuelva
Un problema de accesibilidad arreglado vuelve con el siguiente rediseño si nadie lo vigila. Dos prácticas lo evitan:
- axe en el pipeline, para lo que se puede verificar con reglas (lección 6);
- una prueba manual de teclado en los flujos críticos antes de cada salida importante, que toma minutos.
Cierre del curso
Principios y niveles de WCAG 2.2, teclado, lectores de pantalla, contraste y reflujo, automatización y reporte: es lo que necesita un QA para que la accesibilidad deje de ser un tema de nadie. En proyectos del Estado, y para quien vende en Europa, ya es un requisito. En todos los demás, es la diferencia entre un producto que cualquiera puede usar y uno que deja gente afuera sin que nadie lo note.
Comprueba lo aprendido en el quiz y arma el informe de tus tres flujos en el reto final.
Compruébalo
0/3Responde sin mirar atrás. Verás la explicación al instante.
1. ¿Qué hace que un reporte de accesibilidad se arregle rápido?
2. Un menú no funciona con teclado en el flujo de pago. ¿Qué prioridad tiene?
3. La empresa propone instalar un widget de accesibilidad que se superpone al sitio. ¿Qué responde QA?
Reto final: el informe de tus tres flujos
Junta los hallazgos de las lecciones anteriores en un informe: cada problema con criterio, nivel, quién queda afuera, pasos, evidencia y lo que se espera.
Ordénalo por prioridad y preséntaselo al equipo con una recomendación: qué se arregla antes de la próxima salida y qué entra al plan.