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 comme une série de tests classés par ordre chronologique, 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 du 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 tous les 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 significatifs lors de l'interaction avec le site.
• Modéré: Certains obstacles existent, mais le contenu de base reste accessible.
• Mineur: Des problèmes moins sévères 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 propose deux types de comparaisons pour les projets Git. Comparaisons inter-branches apparaissent dans la vue des branches, où chaque branche est comparée à la dernière exécution du pipeline sur la branche par défaut (cela montre ce qui changerait si vous fusionniez maintenant). Comparaisons intra-branche apparaissent dans la vue des commits, où chaque commit est comparé au commit précédemment scanné sur la même branche (cela vous indique ce qu'un commit spécifique a introduit ou corrigé). 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 l' Action GitHub, elle peut automatiquement poster un commentaire sur la PR avec un résumé et un lien vers les résultats complets.

Pour approfondir 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 la vue Branches, cliquez sur Voir les commits sur n'importe quelle branche pour voir ses commits analysés individuellement. Contrairement aux comparaisons interbranches dans la vue Branches, la vue Commits utilise des comparaisons intrabranches :

• 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 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, l'action Axe Developer Hub GitHub Action peut bloquer les PR qui introduisent des erreurs d'accessibilité.
• Pour d'autres plateformes comme GitLab ou Bitbucket, utilisez l' API de service REST pour interroger les résultats et faire échouer votre pipeline lorsque des problèmes sont détectés.
• 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 :

• L' API de service REST 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 plus de détails sur les rôles et les autorisations, consultez 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 des résumés de 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.