Has recorrido las tres capas de evaluación: automática (06-02), manual (06-01) y con usuarios reales (06-03). El resultado es un montón de hallazgos heterogéneos: violaciones de axe, notas de tu checklist manual, citas de Marta, tiempos de Lucía. Ahora viene la parte que separa una auditoría útil de un PDF que nadie lee: interpretar esos resultados y actuar sobre ellos con criterio. Un informe con 200 hallazgos sin prioridad paraliza; uno con 6 hallazgos bien ponderados y convertidos en tareas mueve el producto. En esta lección aprenderás a leer un informe, entender severidad e impacto, priorizar, descartar falsos positivos y cerrar el círculo para que los problemas no vuelvan.

1. Anatomía de un hallazgo
2. Severidad frente a impacto en el usuario
3. Priorizar: no todo es urgente
4. VPAT / ACR: el informe de conformidad
5. Descartar falsos positivos
6. De hallazgo a tarea de remediación con "criterio de hecho"
7. Informe de auditoría de Cursalia (ejemplo)
8. Prevenir regresiones: accesibilidad en la Definition of Done

Un hallazgo bien documentado —venga de una herramienta o de una sesión con usuarios— tiene siempre estos campos. Si un informe no los trae, exígelos: sin ellos no se puede actuar.

El campo origen importa más de lo que parece: un hallazgo que aparece en axe y en una sesión con usuarios es incuestionable; uno que solo salió de una herramienta puede ser un falso positivo (sección 5).

Cuidado con confundir dos cosas:

• Severidad técnica (la que asigna la herramienta): axe dice "crítico/serio/moderado/menor" según su catálogo de reglas. Es genérica, no conoce tu producto.
• Impacto en el usuario: cuánto daño real causa en tu contexto. Depende de si bloquea una tarea y de a cuánta gente afecta.

Un modelo simple para clasificar el impacto:

La clave: un fallo que axe marca como "moderado" puede ser bloqueante en tu producto si cae en el botón de matrícula, y uno "crítico" de axe puede ser menor si está en una página que nadie visita. La severidad de la herramienta es el punto de partida, no la sentencia.

Priorizar es ponderar impacto × alcance. Dos ejes:

• Gravedad para quien lo sufre: ¿bloqueante, serio o menor? (sección 2).
• Alcance: ¿en cuántas páginas aparece y con qué frecuencia se usan? Un fallo en la ficha de curso y el catálogo (las páginas más visitadas de Cursalia) afecta a casi todos los usuarios; el mismo fallo en la página "Aviso legal" afecta a poquísimos.

Regla práctica: primero lo bloqueante en páginas muy usadas; deja para el final lo menor en páginas marginales. Y si algo es trivial de arreglar (5 minutos) aunque sea menor, hazlo ya: sale gratis.

Cuando una organización (o un cliente que va a comprar Cursalia) quiere saber "oficialmente" cómo de accesible es, se usa un documento estándar:

• VPAT (Voluntary Product Accessibility Template): la plantilla, publicada por el ITI. Es el formato en blanco.
• ACR (Accessibility Conformance Report): el VPAT ya rellenado para tu producto — el informe resultante.

Recorre criterio por criterio (WCAG, y a veces la norma EN 301 549 europea o la Sección 508 de EE. UU.) y marca cada uno con un nivel de soporte:

Para qué sirve: es el documento que un comprador (una universidad, una empresa) pide antes de contratar un e-learning. Un ACR honesto —que reconoce sus "Partially Supports"— genera más confianza que uno que jura "Supports" en todo. No lo confundas con el informe de auditoría interno (secciones 1-3): el ACR es de cara a terceros; la auditoría es tu lista de trabajo.

Antes de crear tareas, filtra el ruido (lo vimos en 06-02):

• Reproduce el hallazgo a mano: si axe marca "contraste bajo" en un texto que resulta estar oculto o sobre imagen decorativa, no es un problema real.
• Verifica el contexto: un aria-* marcado como inválido puede ser correcto para tu patrón concreto.
• Cruza orígenes: si algo aparece en la herramienta pero ni tú a mano ni los usuarios lo notáis, sospecha. Si aparece en varios orígenes, es sólido.

Documenta por qué descartas cada falso positivo. Un hallazgo silenciado sin justificación se convierte, meses después, en "¿por qué ignoramos esto?".

Un hallazgo no es accionable hasta que es una tarea con un criterio de "hecho" (definition of done) verificable. Compara:

• Mal (no accionable): "Mejorar accesibilidad del catálogo".
• Bien (accionable): "Dar nombre accesible al botón de favorito (button.fav-btn). Hecho cuando: NVDA anuncia 'Añadir a favoritos, botón' y axe ya no reporta button-name."

El criterio de "hecho" debe decir cómo se comprueba y con qué prueba (automática, manual o de usuario), cerrando el círculo con las tres lecciones anteriores.

Auditoría combinada de Cursalia (axe + checklist manual de 06-01 + sesión con usuarios de 06-03). Hallazgos priorizados:

Plan de remediación, cada hallazgo mapeado a la lección del curso donde está la solución:

Observa dos cosas: los tres hallazgos más graves (P1) salieron de usuarios y de lo manual, no de la herramienta — justo el mensaje del módulo. Y cada tarea remite a dónde ya aprendiste a arreglarla: la evaluación cierra el bucle con la construcción.

Arreglar los 6 hallazgos no sirve de nada si dentro de dos sprints vuelven. Para que no regresen, la accesibilidad entra en la Definition of Done del equipo: una historia no está "terminada" hasta que cumple criterios de accesibilidad. Ejemplo de checklist de DoD para Cursalia:

Así se cierra el círculo de todo el Módulo 6: automático para no regresar, manual para el juicio, usuarios para la usabilidad, e informe para priorizar y verificar. La accesibilidad deja de ser una auditoría puntual y se vuelve parte del proceso.

• Tratar la severidad de la herramienta como verdad absoluta: pondérala por impacto real y alcance en tu producto.
• Priorizar por "lo fácil" en vez de por impacto: arreglar 20 cosas menores mientras un bloqueante sigue vivo es mala gestión (salvo que lo menor sea trivial: eso sí, cae).
• Confundir ACR con auditoría interna: el ACR es para terceros; la auditoría es tu backlog. No mezcles.
• Cerrar tareas sin criterio de "hecho": "ya lo miré" no es done. Define cómo se verifica y con qué prueba.
• No documentar falsos positivos: se reabren eternamente.
• Arreglar y no blindar: sin accesibilidad en la Definition of Done, todo regresa.
• Consejo: en el informe, ordena por prioridad y pon el impacto en el usuario en lenguaje humano ("Marta no sabe si se ha matriculado"), no solo el código WCAG. Convence más y prioriza mejor.

Ejercicio 1. axe marca como "crítico" un alt ausente en un icono decorativo del footer (aparece en todas las páginas) y como "serio" que el mensaje de matrícula con éxito no se anuncie (solo en el flujo de compra). Según tu criterio de impacto, ¿cuál priorizas y por qué la severidad de la herramienta aquí engaña?

Ejercicio 2. Un cliente universitario pide "el VPAT de Cursalia" antes de contratar. Explica qué le entregas exactamente (VPAT vs ACR), qué estados de conformidad puede tener cada criterio y por qué conviene ser honesto con los "Partially Supports".

Ejercicio 3. Convierte este hallazgo en una tarea accionable con criterio de "hecho": "Contraste del precio insuficiente (4.35:1) en la ficha de curso, WCAG 1.4.3 AA, detectado por Pa11y." Indica también con qué prueba verificarías el arreglo.

Solución 1. Priorizas el mensaje de matrícula no anunciado, aunque axe lo marque "serio" y el alt "crítico". Razón: el mensaje no anunciado es bloqueante —Marta no puede confirmar si se matriculó, en el flujo de compra, que es esencial y muy usado—, mientras que el alt en un icono decorativo es menor (un lector lo ignora sin perder información) por mucho que aparezca en todas las páginas. La severidad de la herramienta es genérica y no sabe qué tarea bloquea cada fallo en tu producto; hay que reinterpretarla por impacto y alcance reales.

Solución 2. Le entregas un ACR: el VPAT (la plantilla del ITI) ya rellenado para Cursalia. Recorre cada criterio WCAG (y posiblemente EN 301 549 / Sección 508) marcándolo como Supports, Partially Supports, Does Not Support o Not Applicable. Conviene ser honesto con los "Partially Supports" porque un ACR realista genera confianza y evita responsabilidad por afirmaciones falsas; jurar "Supports" en todo y que luego el cliente encuentre barreras destruye la credibilidad y puede acarrear consecuencias contractuales/legales.

Solución 3. Tarea: "Ajustar el color del precio en la ficha de curso para alcanzar un contraste ≥ 4.5:1 sobre su fondo (WCAG 1.4.3 AA)." Criterio de "hecho": el cuentagotas de contraste de las DevTools marca ✓ AA para ese texto y Pa11y/axe ya no reportan el error de contraste en #precio-curso. Verificación: prueba automática (Pa11y/axe en CI) más una comprobación manual rápida con el color picker de 06-01. (El cómo ajustar el color es del Módulo 4, lección 04-04.)

Con esta lección cierras el Módulo 6: ya no solo sabes construir interfaces accesibles, sino verificar que lo son y actuar sobre los resultados. Dominas el ciclo completo —automático, manual, usuarios e informe— sobre páginas "normales": una ficha de curso, un catálogo, un formulario de matrícula. Pero la web real es más difícil que eso. ¿Qué pasa cuando el contenido cambia sin recargar y hay que anunciarlo (el hallazgo P1 de Marta apunta justo ahí)? ¿Cuando toda la aplicación es una SPA y la navegación no recarga la página? ¿Cuando Cursalia se traduce a varios idiomas y hay que gestionar lang, dirección del texto y localización? ¿Y hacia dónde va el estándar con WCAG 3.0? Todo eso —interacciones complejas y contenido dinámico, accesibilidad en SPAs, internacionalización/localización y tendencias futuras— es el Módulo 7, donde llevamos lo aprendido al terreno avanzado.