Résultats et rapports

Chaque analyse renvoie un unique objet JSON. Les quatre formats de rapport ci-dessous sont générés à partir de ce même objet, chacun pensé pour un lecteur différent : une personne qui parcourt un onglet de navigateur, un tableau de bord d’analyse de code qui ne comprend que SARIF, une vue de tests de CI qui lit JUnit, ou le format de rapport d’implémentation du W3C lui-même. Choisissez la forme adaptée à la personne qui va réellement le lire.

Schéma de sortie

Le contrat exact que renvoie chaque runner, et celui dont dérive chaque autre format de rapport : une enveloppe de résultat de premier niveau, une entrée par règle (y compris chaque pass et notApplicable, jamais une simple liste de violations), le détail de chaque occurrence jusqu’à l’élément signalé, des codes d’incertitude explicites pour tout ce qu’une règle n’a pas pu trancher, et les agrégations composites par critère de succès WCAG. Chaque constat non tranché d’une règle de core dit comment une personne y répond, et certains indiquent de quel côté penchent les indices de la page (une tendance), si bien qu’une revue commence par les échecs probables plutôt que par une liste à plat. À lire une fois si vous construisez quoi que ce soit sur un résultat brut. Voir Schéma de sortie pour la structure complète.

Rapport HTML

Un seul fichier HTML qui s’ouvre dans n’importe quel navigateur, sans serveur ni étape de build. Un résumé en langage clair en haut, les échecs, puis les constats à vérifier, répartis entre échecs probables, réussites probables et ceux que seule une personne peut juger, avec, pour ceux des règles de core, les étapes pour les vérifier, une agrégation WCAG regroupée par niveau de conformité, issue des résultats composites du moteur lui-même, et un tableau complet consultable en dessous pour qui veut creuser. C’est le rapport à remettre à un relecteur qui ne veut pas lire la sortie brute. Voir Rapport HTML.

Rapport SARIF

Envoyez une analyse directement dans GitHub Code Scanning ou tout autre tableau de bord compatible SARIF, sans écrire de convertisseur vous-même. Les violations deviennent des résultats SARIF avec une empreinte stable, fondée sur le contenu, si bien qu’une baseline / allowlist filtre toujours de façon fiable et qu’un tableau de bord peut suivre un constat d’un commit à l’autre au lieu de le perdre dès qu’un numéro de ligne change. Un journal sans résultat signifie que rien n’a échoué ni ne demande de revue parmi les vérifications exécutées ; ce n’est pas une déclaration de conformité. Une option relève en erreurs les constats qui échouent probablement, pour un build qui bloque sur eux sans bloquer sur chaque question. Voir Rapport SARIF.

Rapport JUnit

Affichez les résultats d’accessibilité dans la vue de tests dont votre CI dispose déjà (le widget de merge request de GitLab, l’onglet Tests d’Azure DevOps, Jenkins, CircleCI), à côté de vos tests unitaires. Chaque critère WCAG est une suite et chaque règle un test : un défaut répété sur une page est un seul test en échec, et les décomptes restent stables d’une exécution à l’autre. cantTell arrive sous forme de test ignoré, visible sans faire passer le build au rouge, sauf si vous choisissez de faire échouer le build sur ceux qui échouent probablement. Les noms des suites sont les mêmes dans toutes les langues : l’historique des tests ne repart pas de zéro quand la langue de l’analyse change. Une suite verte signifie que les règles exécutées pour un critère n’ont rien trouvé, pas que le critère est satisfait. Voir Rapport JUnit.

Rapport EARL

Un rapport d’implémentation W3C EARL/JSON-LD, lisible par machine, qui atteste le résultat de chaque règle, pas seulement les échecs. C’est le format que le groupe communautaire ACT Rules accepte comme rapport d’implémentation : exécuté sur les cas de test ACT, il consigne le résultat obtenu pour chacun, ce qui permet de vérifier comment le moteur applique chaque règle plutôt que de simplement l’affirmer. Il ne s’agit ni d’une certification ni d’une preuve de conformité WCAG : figurer parmi les implémentations ACT n’est pas une validation par le W3C. Voir Rapport EARL.