Planificar una auditoría: tiempos, equipo y evidencias

Una auditoría bien planificada se entrega a tiempo, se puede defender y resulta útil para el equipo que tiene que corregir. Una mal planificada acaba con el auditor evaluando a las dos de la mañana la pantalla de pago sin usuario de pruebas. Esta lección traduce WCAG-EM (se abre en una ventana nueva) a un plan de trabajo con fases, estimación de esfuerzo, reparto de tareas y un sistema de evidencias que después alimentará el informe.

Fases y entregables

Estimar el esfuerzo

La estimación realista parte de la muestra. Un orden de magnitud útil, que cada equipo debe ajustar con su experiencia:

• Página sencilla (texto, imágenes, navegación compartida): 1-2 horas de evaluación manual completa a nivel AA la primera vez; menos para páginas que comparten plantilla y componentes ya evaluados.
• Página con formulario, tabla compleja o componentes ARIA: 2-4 horas.
• Proceso completo de 5-6 pasos: 4-8 horas, porque hay que recorrerlo con teclado, con dos lectores de pantalla y al menos en móvil.
• Documentos PDF: 1-3 horas por documento según su longitud y estructura.

A eso se suman la exploración (10-15 % del total), el análisis y la redacción (25-35 %) y la presentación. Un error típico es olvidar los tiempos de preparación de entornos: instalar versiones concretas de NVDA, actualizar JAWS, disponer de un iPhone y un Android reales (los emuladores no sustituyen a VoiceOver ni a TalkBack).

Equipo y roles

WCAG-EM recomienda que el evaluador conozca a fondo WCAG, tecnologías web y tecnologías de apoyo. En equipos de más de una persona conviene repartir por competencias:

• Auditor principal: alcance, muestra, decisiones de criterio, informe final y defensa ante el cliente.
• Evaluadores: pruebas por página y criterio, registro de evidencias. Si son varios, cada uno asume páginas completas (no criterios sueltos) para mantener el contexto, y se calibran al inicio evaluando juntos dos páginas y comparando resultados.
• Especialista en tecnologías de apoyo: idealmente una persona usuaria real de lector de pantalla o de control por voz. Su revisión detecta problemas de usabilidad que un auditor vidente pasa por alto, aunque recuerda que la conformidad la decide el criterio, no la experiencia de una persona.
• Revisor: alguien que no ha evaluado revisa el informe buscando inconsistencias (mismo problema con dos criterios distintos, severidades incoherentes, capturas sin contexto).

Acordad desde el principio un vocabulario común de veredictos (cumple, no cumple, no se puede determinar, no aplica y no comprobado) y de severidades, y una única hoja de registro para evitar reconciliar formatos al final.

Herramientas de registro

Para auditorías pequeñas basta una hoja de cálculo con una fila por hallazgo: identificador, página o estado, criterio WCAG (número y nombre), nivel, descripción, pasos para reproducir, resultado esperado, resultado observado, tecnología con la que se detectó, severidad, evidencia (enlace a captura o vídeo), recomendación. Para auditorías grandes, muchas organizaciones usan una herramienta específica o un gestor de incidencias (Jira, GitLab) donde cada hallazgo es un ticket que el equipo de desarrollo puede cerrar; eso facilita la reauditoría.

La WCAG-EM Report Tool del W3C es adecuada para estructurar el informe por los cinco pasos y permite exportar a JSON para conservar y reutilizar la evaluación.

Evidencias: qué recoger y cómo

La evidencia es lo que convierte una opinión en un hallazgo. Para cada problema conviene recoger:

1. Captura de pantalla anotada con el elemento señalado y, si procede, el estado (menú abierto, error de validación). Incluye la URL y la fecha en el nombre del fichero o en la anotación.
2. Fragmento de código relevante tal como lo entrega el navegador (DOM inspeccionado, no el código fuente del servidor), por ejemplo el <img> sin alt o el <div onclick> sin rol ni tabindex.
3. Salida de la tecnología de apoyo: el texto del visor de voz de NVDA o del historial de voz de JAWS, o un vídeo corto con el audio del lector de pantalla.
4. Resultado de la herramienta automática si el fallo lo detecta (identificador de regla de axe, informe de WAVE), con la advertencia de que la herramienta confirma, no decide.
5. Medición cuando el criterio es cuantitativo: ratio de contraste con los dos colores en hexadecimal, tamaño del objetivo en píxeles CSS, anchura a la que se rompe el reflow.

Riesgos habituales y cómo cubrirlos

• Entornos que cambian durante la auditoría: acuerda una ventana de congelación o evalúa en preproducción con una versión etiquetada; anota la fecha y la versión en cada evidencia.
• Sin datos de prueba: pide usuarios, tarjetas y certificados de prueba en el documento de alcance; sin ellos, los procesos quedan fuera y el informe debe decirlo.
• Alcance que crece: cualquier página añadida pasa por el procedimiento de muestra y se registra como ampliación.
• Contenido de terceros: identifícalo en la exploración y acuerda cómo se trata en el informe.
• Protección de datos: no uses datos reales de ciudadanos ni los guardes en capturas; si evalúas en producción con una cuenta real, anonimiza las evidencias.

Resumen

• Planifica en cinco fases con entregables claros: alcance firmado, inventario y muestra, resultados, informe borrador y final.
• Estima a partir de la muestra: la evaluación manual y la redacción son la mayor parte del esfuerzo; la parte automática es pequeña.
• Reparte por páginas completas, calibra al equipo al inicio y reserva un revisor que no haya evaluado.
• Registra cada hallazgo con criterio, pasos, esperado/observado, tecnología, severidad y evidencia reproducible.
• Cubre los riesgos: entorno congelado, datos de prueba, alcance controlado, contenido de terceros y protección de datos.