Questions fréquemment posées

Concepts

Quelle est la différence entre un projet Git et un projet sans Git ?

Developer Hub organise vos résultats différemment selon que vos tests utilisent Git :

• Un projet Git associe les résultats d'accessibilité aux branches et aux commits, vous permettant de suivre les problèmes jusqu'aux changements de code spécifiques.
• Un projet sans Git organise les résultats en tant que série de tests ordonnés par horodatage, sans aucune donnée Git.
• Les données Git sont disponibles lors de l'utilisation d'Axe Watcher, Axe CLI ou Axe DevTools pour les API web (qui téléchargent les résultats via le CLI). Les projets mobiles sont toujours sans Git.

Voir Comprendre vos résultats et les entrées de glossaire pour Git et sans Git pour plus de détails.

Quel est le seuil a11y et comment le configurer ?

Le seuil a11y reflète la tolérance de votre organisation aux problèmes d'accessibilité et détermine ce qui compte comme un échec dans votre pipeline CI/CD :

• Il est calculé à partir de deux critères : si l'on doit compter tous les problèmes ou seulement les nouveaux, et quels niveaux d'impact inclure (Critique est toujours inclus).
• Seuls les administrateurs de projet peuvent configurer le seuil.

Voir Modifier le seuil A11y pour plus de détails.

Que signifient les niveaux d'impact (Critique, Grave, Modéré, Mineur) ?

Chaque violation d'accessibilité se voit attribuer un des quatre niveaux d'impact, du plus sévère au moins sévère :

• Critique : Les utilisateurs handicapés sont complètement bloqués pour accéder ou interagir avec une fonctionnalité.
• Grave : Les utilisateurs handicapés rencontrent des obstacles importants lorsqu'ils interagissent avec le site.
• Modéré : Certains obstacles existent, mais le contenu de base reste accessible.
• Mineur : Problèmes moins graves qui nécessitent néanmoins une résolution pour une conformité complète.

Voir le Glossaire pour des définitions détaillées.

Pourquoi les mêmes problèmes sont-ils sans cesse signalés comme nouveaux ?

Pour décider si un problème est nouveau, Developer Hub compare chaque résultat avec l'exécution précédente par règle, sélecteur d'élément et URL, comme décrit dans le Doublon du glossaire. Si le même problème sur le même élément est signalé comme nouveau à chaque exécution, l'un d'eux change entre les exécutions. Il y a deux causes communes.

L'URL change d'une exécution à l'autre. L'URL est comparée dans son intégralité, ce qui signifie qu'un ID de session, un horodatage, un paramètre de cache ou toute autre valeur dynamique dans la chaîne de requête fait que chaque exécution semble être une page différente, et chaque problème sur une URL non encore vue est signalé comme nouveau. Aucune option ne normalise les URLs avant la comparaison, donc la solution est de rendre les URLs de vos tests déterministes : supprimez ou corrigez les paramètres volatils dans la configuration de vos tests afin que la même page génère la même URL à chaque exécution.

Les IDs ou les classes des éléments changent d'une exécution à l'autre. Les frameworks qui génèrent des identifiants comme #component-a1b2c3d4 ou .form-field-xyz789 à chaque rendu modifient le sélecteur de l'élément, de sorte qu'il ne correspond plus à l'élément enregistré précédemment. Définir l'option d'exécution ancestry sur true résout ce problème, car le sélecteur d'ascendance décrit l'élément par sa position dans l'arbre DOM et ne contient ni IDs ni classes :

axe: {
  runOptions: {
    ancestry: true
  }
}

Voir Utilisation des sélecteurs dynamiques pour l'explication complète, y compris la configuration Java et les compromis de l'activation de ancestry.

Comparaisons

Chaque décompte de « nouveau problème » ou « problème résolu » dans Developer Hub provient de la comparaison de l'analyse actuelle avec une analyse de base de référence. L'analyse qui compte comme la base de référence dépend de l'endroit où vous regardez :

• Comparaisons inter-branches apparaissent dans la vue des branches. Ils comparent l'analyse la plus récente de votre branche avec la plus récente exécution de pipeline de la branche par défaut. Une exécution de pipeline est une analyse déclenchée par votre pipeline CI/CD, par opposition à une exécution locale depuis la machine d'un développeur ; Developer Hub les distingue pour toujours savoir quelle analyse de la branche par défaut est la plus autoritaire. Cela répond à la question « qu'est-ce qui changerait si je fusionnais maintenant ? »
• Comparaisons intra-branche apparaissent dans la vue des commits. Ils comparent l'analyse d'un commit avec l'analyse du commit précédent qui a des résultats sur la même branche, ce qui n'est pas nécessairement le commit immédiatement précédent dans votre historique Git : un commit sans analyse est ignoré. Cela répond à la question « qu'est-ce que ce commit spécifique a introduit ou corrigé ? »

Le Action GitHub n'est pas un troisième type de comparaison. Les décomptes qu'il affiche dans une demande de fusion sont la comparaison au sein de la branche pour le commit actuel, pas une comparaison avec la branche par défaut, ce qui est une source courante de confusion puisque l'on s'attend souvent à ce qu'une vérification de PR compare avec la branche dans laquelle vous envisagez de fusionner.

Voir Comprendre vos résultats pour avoir une vue d'ensemble complète.

Comment déterminer ce qui change d'une version à l'autre ?

La vue des branches dans un projet Git vous permet de suivre les changements d'accessibilité entre les versions à l'aide d'une comparaison inter-branches :

• Le dernier commit scanné de chaque branche est comparé à la dernière exécution du pipeline sur votre branche par défaut.
• La comparaison montre le nombre total de problèmes, les nouveaux problèmes introduits, les problèmes résolus, et toute modification du nombre d'états de page analysés.

Pour voir ce qui a changé dans les commits individuels au sein d'une branche, voir Comment puis-je voir ce qui a changé d'un commit à l'autre dans une branche ?

Comment puis-je déterminer l'impact d'une pull request ?

Exécutez votre suite de tests sur la branche de la pull request afin que les résultats apparaissent dans Axe Developer Hub :

• Dans la vue Branches, chaque branche non par défaut affiche une comparaison interbranche avec la branche par défaut, montrant les nouveaux problèmes introduits, les problèmes résolus, et la différence totale.
• Si vous utilisez le Action GitHub, il peut automatiquement poster un commentaire sur le PR avec un résumé et un lien vers les résultats complets.

Pour examiner ce que chaque commit sur la branche a changé, voir Comment puis-je voir ce qui a changé d'un commit à l'autre dans une branche ?

Comment puis-je voir ce qui a changé d'un commit à l'autre dans une branche ?

Depuis l'affichage des branches, cliquez sur Voir les commits sur n'importe quelle branche pour voir ses commits scannés individuellement. Contrairement aux comparaisons entre branches dans l'affichage des branches, l'affichage des commits utilise des comparaisons au sein de la branche :

• Chaque commit est comparé au commit analysé précédent sur cette branche, montrant les nouveaux problèmes, les problèmes résolus, et les changements dans les états de page.
• Seuls les commits où la suite de tests a été exécutée apparaîtront.

Pour voir comment la branche dans son ensemble se compare à la branche par défaut, voir Comment puis-je comparer une branche avec la dernière exécution CI/CD sur la branche par défaut ?

Comment puis-je comparer une branche avec la dernière exécution CI/CD sur la branche par défaut ?

La vue Branches effectue automatiquement une comparaison interbranche pour chaque branche non par défaut par rapport à la dernière exécution du pipeline de la branche par défaut :

• Cela nécessite qu'un administrateur de projet ait configuré Axe Watcher pour fonctionner sur la branche par défaut comme une exécution de pipeline.
• La comparaison montre les problèmes totaux, les nouveaux problèmes, les problèmes résolus, et les différences d'état de page.

Pour voir ce qui a changé dans les commits individuels au sein de cette branche, voir Comment puis-je voir ce qui a changé d'un commit à l'autre dans une branche ?

Comment puis-je obtenir des résultats de comparaison précis avant de créer une pull request ?

Pour la comparaison interbranche la plus précise avant fusion, gardez votre branche de fonctionnalité à jour avec la branche par défaut :

1. Fusionnez la branche par défaut dans votre branche de fonctionnalité (par exemple, git merge main) avant d'exécuter votre suite de tests.
2. Poussez le commit de fusion pour qu'Axe Developer Hub puisse analyser la branche mise à jour.
3. La vue Branches comparera ensuite votre branche à la dernière exécution du pipeline sur la branche par défaut, ne montrant que les changements d'accessibilité que votre branche introduit réellement.

Si votre branche de fonctionnalité est en retard par rapport à la branche par défaut, la comparaison peut révéler des problèmes qui ont déjà été résolus dans la branche par défaut mais qui n'ont pas encore été fusionnés dans votre branche de fonctionnalité. Fusionner d'abord la branche par défaut élimine ces faux positifs et réduit les surprises lorsque la pull request est fusionnée.

Pourquoi vois-je des problèmes signalés comme nouveaux ou résolus alors qu'un ensemble différent de tests a été exécuté ?

Une comparaison n'a de sens que lorsque le même ensemble de tests a été exécuté des deux côtés :

• Si une exécution visite une page que l'exécution de base n'a jamais visitée, chaque problème sur cette page est signalé comme nouveau, car il n'y a rien pour le comparer.
• Si une exécution ignore une page que la base couvrait, les problèmes de cette page apparaissent comme résolus même si personne n'a rien corrigé, car ils n'ont simplement pas été testés.
• Deux exécutions couvrant des suites de tests réellement différentes ne devraient pas du tout être comparées ; le résultat ne vous dira rien d'utile.

Ce n'est pas quelque chose qu'un paramètre peut corriger. Voir Bonnes pratiques pour des comparaisons précises pour savoir comment configurer votre suite de tests afin que les comparaisons restent significatives.

Bonnes pratiques pour des comparaisons précises

• Utiliser un projet par ensemble de tests. Un projet devrait correspondre à une suite de tests. Pointer plusieurs suites vers un seul projet signifie que chaque exécution se compare à une base produite par un ensemble de tests différent, et les nouveaux compteurs de résolus cessent d'avoir un sens.
• Exécuter le même ensemble de tests à chaque fois. Modifier ce que la suite couvre modifie ce que la comparaison peut vous dire. Lorsque la suite croît légitimement, attendez-vous à une augmentation ponctuelle des nouveaux problèmes lors de l'exécution qui ajoute la couverture.
• Configurer une exécution de pipeline sur votre branche par défaut. Les comparaisons inter-branches mesurent une branche par rapport à la dernière exécution de pipeline sur la branche par défaut. Sans cela, il n'y a pas de base du tout, et chaque problème est signalé comme nouveau, ce qui est la version la plus déroutante de ce symptôme. Sa mise en place est une tâche d'administration de projet ; voir Informations sur le pipeline.

CI/CD

Comment puis-je m'assurer qu'aucun nouveau problème d'accessibilité n'est fusionné dans mon code ?

Intégrez Axe Developer Hub dans votre pipeline CI/CD pour que les vérifications d'accessibilité soient exécutées automatiquement à chaque commit ou pull request :

• Si vous utilisez GitHub, le Axe Developer Hub GitHub Action peut bloquer les PRs qui introduisent des erreurs d'accessibilité.
• Pour d'autres plateformes comme GitLab ou Bitbucket, utilisez le REST Service API pour interroger les résultats et échouer votre pipeline lorsqu'il détecte des problèmes.
• Vous pouvez affiner ce qui est considéré comme un échec en configurant le seuil d'accessibilité.

Comment puis-je intégrer Axe Developer Hub à mon pipeline CI/CD si je n'utilise pas GitHub ?

Vous pouvez utiliser l'API de service REST pour vous intégrer à n'importe quelle plateforme CI/CD :

• Le REST Service API vous permet d'interroger Axe Developer Hub pour obtenir des résultats après l'exécution de votre suite de tests.
• L'API renvoie le nombre de problèmes, les nouvelles violations, les violations résolues, et un lien vers les résultats complets dans Developer Hub.
• Vous pouvez utiliser cette réponse pour valider ou échouer votre pipeline dans GitLab, Bitbucket, Jenkins ou toute autre plateforme.

Gestion de projet

Comment puis-je voir les analyses d'accessibilité des autres membres de l'équipe sur un projet ?

Tous les membres du projet peuvent voir tous les résultats au sein d'un projet partagé une fois qu'ils ont été ajoutés :

• Ajoutez des membres de l'équipe via la page des paramètres Membres.
• Sur les projets Git, la vue Branches affiche les résultats groupés par clé API, vous permettant de voir qui a réalisé chaque analyse.

Pour des détails sur les rôles et permissions, voir Configurer des projets pour une utilisation en équipe.

Comment puis-je exporter mes résultats d'accessibilité ?

Developer Hub propose plusieurs façons d'exporter vos données :

• Depuis la vue récapitulative des problèmes, cliquez sur le bouton Exporter les problèmes pour télécharger les résultats au format CSV ou JSON.
• Pour un accès programmatique, utilisez le REST Service API pour interroger les résultats pour un commit et un projet spécifiques.

Voir Obtenez des résultats par programmation pour plus d'options.