Comprendre les résultats

Après avoir suivi les instructions d'installation de votre kit d'outils, vous génèrerez des résultats qui sont envoyés à Developer Hub chaque fois que vous exécutez votre suite de tests. Dans Developer Hub, vous pouvez visualiser les nouveaux problèmes d'accessibilité ainsi que ceux déjà existants et suivre les tendances au fil du temps.

Comprendre la structure de votre projet

Developer Hub organise vos données d'accessibilité différemment selon que vos tests de bout en bout utilisent Git pour le contrôle de version :

Si vous utilisez Git, vous pourrez voir les différentes branches de votre projet et les commits individuels effectués sur ces branches. La structure est la suivante :
Projet → Branches → Commits → Liste des problèmes → Détails du problème

Si vous n'utilisez pas Git avec votre projet web, ou si vous visualisez un projet mobile, vous verrez des exécutions de test individuelles et vous pourrez naviguer vers les problèmes trouvés dans chaque exécution. La structure est la suivante :
Projet → Exécutions de test → Liste des problèmes → Détails du problème

Travailler avec vos résultats

Lorsque vous ouvrez un projet, vous verrez soit une liste de branches (projets Git), soit des exécutions de test (projets sans Git).

Vos résultats en un coup d'œil

Vous verrez les informations suivantes renvoyées par vos tests d'accessibilité :

• Pour projets Git : Nom de la branche, dernier SHA de commit, et message de commit pour le test de bout en bout en cours d’exécution
• Pour projets sans Git : Horodatage de l'exécution du test
• Nombre de problèmes dépassant le seuil d'accessibilité
• Informations sur le package et la version de l'outil d'accessibilité que vous utilisez
• Résumé comparatif montrant le nombre total de problèmes et le nombre de scans
• Un comptage des nouveaux problèmes introduits et des problèmes qui ont été résolus (projets web uniquement)
• Score d'accessibilité (projets mobiles uniquement) : Un pourcentage (0–100 %) indiquant à quel point les analyses de la session étaient accessibles, détaillé ci-dessous dans Score d'accessibilité (Projets Mobiles Uniquement)
• Bouton 'Voir les commits' (projets Git uniquement) pour explorer les commits individuels
• Bouton 'Voir les problèmes' pour voir la liste complète des problèmes

Score d'accessibilité (Projets Mobiles Uniquement)

Le score d'accessibilité est un pourcentage (0–100 %) affiché sur les pages de rapport de session mobile. Un score plus élevé signifie moins de problèmes d'accessibilité graves pendant la session.

Le score est calculé en deux étapes :

1. Chaque analyse est notée basé sur son problème d'accessibilité le plus grave :

   • 100 % — seulement des problèmes mineurs, ou aucun problème
   • 80 % — au moins un problème modéré ; aucun problème grave ou critique
   • 40 % — au moins un problème grave ; aucun problème critique
   • 0 % — au moins un problème critique

2. Le score de la session est la moyenne de tous les scores d'analyse.

Par exemple, une session avec trois analyses, une avec seulement des problèmes mineurs, une avec un problème grave, et une avec un problème critique, obtiendrait (100 + 40 + 0) / 3 ≈ 47 %.

Les sessions sans analyses affichent un état vide plutôt que 0 %.

Pour la spécification complète de la formule, voir Calculer un Score dans la documentation Axe DevTools Mobile.

Bannière d'avertissement de configuration (Projets mobiles uniquement)

Les pages de session mobile peuvent afficher une bannière d'avertissement : « Cette analyse a été effectuée avec une configuration différente de celle que votre organisation utilise actuellement. Le nombre de problèmes et le score d'accessibilité peuvent ne pas refléter votre configuration actuelle. » (ou « Ces analyses ont été effectuées... » pour une session avec plusieurs analyses).

Renommer les sessions

Par défaut, les sessions sont identifiées par leur branche Git et les informations de commit (projets Git) ou par horodatage (projets sans Git). Vous pouvez définir un nom d'affichage personnalisé pour toute session afin de faciliter l'identification des exécutions de scan spécifiques.

Les noms personnalisés apparaissent partout dans Developer Hub là où une session est référencée : en-têtes de page, titres de panneaux, fil d'Ariane et étiquettes de comparaison. L'identifiant original Git ou horodaté reste visible dans une zone de métadonnées sur la page des problèmes.

Pour renommer une session, ouvrez la page des problèmes de celle-ci et cliquez sur le bouton d'édition dans l'en-tête de la page. Les administrateurs de projet, les membres du projet et les administrateurs de l'organisation peuvent renommer n'importe quelle session dans le projet.

Informations sur le pipeline

Pour les équipes dont les tests utilisent des données Git avec Axe Watcher, toutes les exécutions peuvent être comparées aux exécutions CI/CD sur la branche par défaut, pour s'assurer que le nouveau code fusionné n'introduit pas de problèmes d'accessibilité supplémentaires. Pour configurer la comparaison, un administrateur de projet doit configurer Watcher pour s'exécuter sur la branche par défaut du dépôt - cela est généralement la branche main (ou master). Cet instance de l'outil doit être configurée comme une exécution de pipeline.

Une fois les données de scan reçues de l'exécution de pipeline désignée sur la branche par défaut, les résultats s'afficheront en haut de la page. Les utilisateurs peuvent choisir de voir divers ensembles de résultats par clé API et voir comment ils se comparent à l'exécution de pipeline sur la branche par défaut.

En savoir plus sur la configuration des exécutions de pipeline avec Axe Watcher dans les environnements d'intégration continue (CI)

Comprendre les comparaisons

Les informations de comparaison fournies pour les projets web vous aident à comprendre ce qui a changé :

• Pour les projets Git :
  • Sur la page affichant toutes les branches de votre projet, vous pouvez voir comment le dernier commit sur chaque branche se compare à la dernière exécution de pipeline sur la branche par défaut.
  • Lorsque vous sélectionnez une branche individuelle à visualiser, vous pouvez voir comment chaque commit unique sur cette branche se compare au commit précédent.
• Pour les projets Gitless : Chaque exécution de test est comparée à l'exécution précédente.

Parce qu'un projet Git est verrouillé sur un seul dépôt lors de sa première session réussie, chaque commit et branche comparés dans ce projet appartiennent toujours à ce même dépôt.

Si vous ne voyez aucune donnée de comparaison, il est probable qu'aucun scan précédent n'était disponible pour la comparer, ou qu'un scan de pipeline n'a pas encore été exécuté sur la branche par défaut.

En savoir plus sur l'utilisation des comparaisons pour suivre les tendances

En savoir plus sur les problèmes d'accessibilité

Après avoir cliqué sur Afficher les problèmes depuis une branche, un commit ou une exécution de test, vous verrez une page de résumé listant et regroupant les violations d'accessibilité par règle et niveau d'impact.

Tableau de comparaison (projets Web uniquement)

Les projets Web affichent un tableau de comparaison en haut montrant :

• Total des problèmes dans les scans actuels et de référence
• Nouveaux problèmes introduits
• Problèmes existants auparavant
• Problèmes qui ont été résolus
• Tous ces éléments sont regroupés par gravité de l'impact (Critique, Grave, Modéré, Mineur)

Note : Les projets mobiles n'incluent pas ce tableau de comparaison.

Liste des règles

Sous la section de comparaison (ou en haut pour les mobiles), vous verrez toutes les règles d'accessibilité violées regroupées par :

• Nom de la règle (que vous pouvez sélectionner pour voir les problèmes individuels)
• Niveau d'impact
• Nombre de violations trouvées pour cette règle

Filtrage et exportation

Avec projets web, utilisez les contrôles de filtre pour vous concentrer sur des problèmes spécifiques :

• Filtrer par niveau d'impact (Critique, Grave, Modéré, Mineur)
• Afficher uniquement les nouveaux problèmes
• Sélectionner des états de page spécifiques

Avec projets mobiles, utilisez le filtre pour sélectionner un ou plusieurs écrans dans la liste, et vous concentrer sur certains résultats.

Exportez vos résultats :

• Web
  • Exportez en format JSON pour partager facilement des résultats détaillés dans un format lisible par l'homme
  • Exportez en CSV pour des tableaux et des rapports
• Mobile
  • Exporter le JSON mobile pour l'ensemble des données de l'analyse (résultats d'accessibilité, captures d'écran et hiérarchie de vues), à utiliser avec Reporter CLI ou lorsque le support Deque demande une exportation d'analyse.
  • Exporter le JSON universel Axe pour l'intégration avec d'autres produits Axe ou vos propres outils.

Les exportations web s'alignent sur vos filtres actuels. Les exportations mobiles (tant le JSON mobile que le JSON universel Axe) incluent toujours tous les résultats de la session, quelle que soit l'application de filtres.

L'exportation JSON universelle d'Axe inclut les résultats Besoin de révision ainsi que les violations. Chaque résultat Besoin de révision apparaît dans la liste des problèmes du fichier (allIssues) à côté des violations, marqué avec needsReview: true, et le fichier comporte également un résumé séparé par règle pour le Besoin de révision. Si vos outils traitent chaque entrée allIssues comme une violation, mettez-les à jour pour ignorer les entrées où needsReview est true. Les résultats Besoin de révision ne sont comptabilisés que dans le propre compte de Besoin de révision du fichier : ils n'ajoutent pas aux totaux des violations ou des impacts, et n'affectent pas le score d'accessibilité. Les résultats Besoin de révision n'apparaissent nulle part dans l'interface utilisateur du Hub Développeur, de sorte que l'exportation est le seul endroit où vous les verrez. L'exportation les inclut indépendamment du paramètre Besoin de révision par défaut de votre organisation dans Configuration Axe.

Page à problème unique

Cliquez sur n'importe quel nom de règle dans la liste des problèmes pour voir les informations détaillées sur chaque violation.

Trouver des problèmes dans votre code

Les projets web fournir :

• Code source de l'élément (extrait HTML)
• Sélecteur CSS pour localiser l'élément
• Expression XPath comme localisateur alternatif
• Tous avec des boutons de copie pour une utilisation facile dans vos outils de développement

Projets mobiles fournir :

• Capture d'écran avec le problème mis en évidence
• Vue des détails : Fournit un contexte pour l'élément problématique
• Vue Hiérarchie d'inspection : Affiche l'arborescence hiérarchique pour que vous puissiez localiser l'emplacement exact et voir les propriétés détaillées de l'élément

Conseils sur la remédiation

Chaque problème inclut :

• Description de la règle expliquant le problème d'accessibilité
• Liens vers Deque University ou des pages de règles mobiles pour obtenir des conseils complets et des exemples de code
• Niveau d'impact et étiquettes d'accessibilité (critères WCAG, meilleures pratiques)
• Navigation pour parcourir toutes les instances de cette violation (par exemple, « 1 sur 5 »)

Partage des problèmes

Cliquez sur Copier le lien du problème en haut de la page pour partager avec votre équipe ou ajouter à votre système de suivi des problèmes.

Autorisations de partage : Les liens de problèmes respectent les paramètres de partage de votre organisation. Les membres de l'équipe ont besoin des autorisations appropriées pour voir les problèmes. Les administrateurs peuvent configurer les paramètres de partage dans :

• Configuration globale - Définir les paramètres de partage à l'échelle de l'organisation
• Paramètres du projet - Accéder et mettre à jour les paramètres pour des projets individuels dans Axe Developer Hub