Resultados e informes
Cada análisis se devuelve como un único objeto JSON plano. Los cuatro formatos de informe siguientes se generan a partir de ese mismo objeto, cada uno pensado para un lector distinto: una persona revisando una pestaña del navegador, un panel de análisis de código que solo entiende SARIF, una vista de pruebas de CI que lee JUnit, o el propio formato de informe de implementación del W3C. Elige la forma que se ajuste a quién va a mirarlo realmente.
| Formato | Uso principal | Audiencia |
|---|---|---|
JSON | Integración, almacenamiento y procesamiento propio | Desarrollo y plataformas |
| HTML | Revisión humana de un análisis concreto | QA y auditoría |
| SARIF | Integración con herramientas de análisis de código | Equipos de desarrollo y seguridad |
| JUnit | Vistas de pruebas de los paneles de CI | Equipos de desarrollo y QA |
| EARL | Interoperabilidad e informes de implementación de reglas ACT | Estándares, investigación y conformidad |
Esquema de salida
El contrato exacto que devuelve cada runner, y del que se deriva cualquier otro formato de informe: un objeto de resultado de nivel superior, una entrada por regla (incluyendo cada pass y notApplicable, nunca una lista de solo violaciones), detalle por ocurrencia hasta el elemento marcado, códigos explícitos de incertidumbre para todo lo que una regla no pudo decidir, y resultados agregados por criterio de conformidad de WCAG. Cada hallazgo sin decidir de una regla de core dice cómo lo responde una persona, y algunos dicen hacia dónde apuntan los indicios de la página (una tendencia), para que una revisión empiece por los fallos probables en lugar de por una lista plana. Un análisis de varios perfiles recoge cada hallazgo una vez y dice qué hace de él cada perfil. Vale la pena leerlo una vez si estás construyendo algo sobre un resultado sin procesar. Ver Esquema de salida para la estructura completa.
Informe HTML
Un único archivo HTML que se abre en cualquier navegador, sin servidor ni paso de compilación. Un resumen en lenguaje llano arriba, los fallos, después los hallazgos que necesitan revisión ordenados en fallos probables, probables cumplimientos y los que solo una persona puede juzgar, los de cada regla de core con los pasos para comprobarlo, un resumen por WCAG agrupado por nivel de conformidad obtenido de los resultados compuestos propios del motor, lo que el análisis deja a una persona criterio por criterio, con los pasos de cada comprobación, y una tabla completa con función de búsqueda debajo para quien quiera profundizar. Este es el informe para entregar a un revisor que no quiere leer la salida sin procesar. Ver Informe HTML.
Informe SARIF
Envía un análisis directamente a GitHub Code Scanning o a cualquier otro panel que consuma SARIF, sin tener que escribir tú mismo un conversor. Las violaciones se mapean a resultados SARIF con una huella estable basada en contenido, así que un Baseline / allowlist sigue filtrando con limpieza y un panel puede seguir un hallazgo a través de commits en lugar de perderlo cada vez que cambia un número de línea. Un registro sin resultados significa que nada falló ni necesita revisión entre las comprobaciones que se ejecutaron; no es una declaración de conformidad. Una opción eleva a errores los hallazgos que probablemente fallan, para una compilación que se condiciona a ellos sin condicionarse a cada pregunta. Ver Informe SARIF.
Informe JUnit
Lleva los resultados de accesibilidad a la vista de pruebas que tu CI ya tiene (el widget de merge requests de GitLab, la pestaña Tests de Azure DevOps, Jenkins, CircleCI), junto a tus pruebas unitarias. Cada criterio de WCAG es una suite y cada regla una prueba, así que un defecto repetido en una página es una sola prueba fallida y los recuentos se mantienen estables entre ejecuciones. cantTell llega como prueba omitida, visible sin poner la compilación en rojo, salvo que decidas hacer fallar la compilación con los que probablemente fallan. Los nombres de las suites son los mismos en todos los idiomas, así que el historial de pruebas no se reinicia cuando cambia el idioma del análisis. Una suite en verde significa que las reglas que se ejecutaron para un criterio no encontraron nada, no que el criterio se cumpla. Ver Informe JUnit.
Informe EARL
Un informe de implementación EARL/JSON-LD del W3C que declara el resultado de cada regla, no solo los fallos: el formato que el grupo comunitario de ACT Rules acepta para los informes de implementación de reglas ACT. Ejecutado sobre los casos de prueba de ACT, registra el resultado de cada uno, así que cómo implementa el motor cada regla se puede examinar en lugar de darse por bueno. No es una certificación ni una evidencia de conformidad con WCAG: figurar como implementación de ACT no supone un aval del W3C. Ver Informe EARL.