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.

Comparaisons

Developer Hub fournit deux types de comparaisons pour les projets Git. Les Comparaisons inter-branches apparaissent dans l'affichage des branches, où chaque branche est comparée à la dernière exécution de pipeline sur la branche par défaut (cela montre ce qui changerait si vous fusionniez maintenant). Les Comparaisons intra-branche apparaissent dans l'affichage des commits, où chaque commit est comparé au commit scanné précédent sur la même branche (cela vous indique ce qu'un commit spécifique a introduit ou corrigé). Voir Comprendre vos résultats pour 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.

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.