Utilisation de l'action GitHub Axe Developer Hub

This page is not available in the language you requested. You have been redirected to the English version of the page.
Link to this page copied to clipboard

Vérifiez automatiquement les PR et les commits pour détecter les défauts d'accessibilité

Not for use with personal data

Nécessite :

note

Pour d’autres pipelines CI/CD (comme ceux sur GitLab, Bitbucket ou CircleCI) ou lors de l’utilisation de Axe DevTools pour les APIs/web CLI, vous pouvez utiliser API de statut de commit de Axe Developer Hub comme base pour votre propre intégration.

Aperçu

L'Action GitHub de Axe Developer Hub vous permet de configurer des workflows GitHub pour les projets web intégrant Axe Watcher, afin de bloquer les commits et les pull requests s'ils contiennent des erreurs d'accessibilité.

Lorsque votre suite de tests modifiée s'exécute, il associe les résultats d'accessibilité avec un SHA du commit Git et envoie ces informations aux serveurs de Deque. L'action GitHub s'exécute après que votre suite de tests fonctionne, et elle interroge les serveurs de Deque pour obtenir les résultats d'accessibilité associés au dernier SHA de commit de la branche actuelle.

Les nouveaux problèmes et les problèmes résolus que l'Action rapporte utilisent le base du commit précédent ayant un scan sur cette même branche, et non de la branche par défaut. Seuls les commits pour lesquels votre suite de tests a effectivement été exécutée possèdent un scan, donc ce commit de base peut être plusieurs commits en arrière. Si ce commit a exécuté un ensemble de tests différent, les décomptes refléteront la différence de couverture plutôt qu'un changement réel ; voir Bonnes pratiques pour des comparaisons précises.

Configuration

  1. Créer une variable d'environnement pour votre ID de projet - Nous recommandons de stocker votre ID de projet dans une variable d'environnement ou une autre variable GitHub. Pour cet exemple, nous allons stocker l'ID de projet en tant que variable d'environnement appelée PROJECT_ID.

  2. Créer un secret pour votre clé API - Pour cet exemple, le secret créé est appelé AXE_DEV_HUB_API_KEY, avec votre clé API personnelle comme valeur, mais vous pouvez nommer le secret comme vous le souhaitez. Il doit être référencé sous le même nom dans le job du workflow. Votre clé API est une donnée d'identification : stockez-la toujours en tant que secret GitHub Actions plutôt que de l'inscrire en dur dans le fichier de workflow.

  3. Ajouter des vérifications d'accessibilité à votre suite de tests - Assurez-vous d'avoir complété les étapes dans configuration du projet pour intégrer les vérifications d'accessibilité dans la suite de tests utilisée dans votre pipeline CI/CD (Axe Watcher).

  4. Modifier votre workflow actuel - Vous devez modifier le workflow de votre exécuteur de tests actuel en .github/workflows et ajouter l'action GitHub après le job qui exécute votre suite de tests.

Exemple de job

Le job suivant l'action de votre suite de tests doit exécuter l'action GitHub de Axe Developer Hub. Référez-vous à l'exemple suivant :

jobs:

# ...
# your-CI-test
# ...

# Add the following new job:
# Be sure to replace <choose_latest_tag> with the appropriate version tag
  axe-dev-hub:
    runs-on: ubuntu-latest
    needs: your-CI-test
    steps:
      - uses: actions/checkout@v5
      - uses: dequelabs/axe-devhub-action@<choose_latest_tag>
        with:
          api_key: ${{ secrets.axe_DEV_HUB_API_KEY }}
          project_id: ${{ env.PROJECT_ID }}

Le job axe-dev-hub dans l'exemple dépend du job qui exécute votre suite de tests, spécifié avec la ligne needs: your-CI-test. Assurez-vous de mettre à jour cette ligne pour qu'elle corresponde au nom du job qui exécute votre suite de tests.

Vous pouvez utiliser plusieurs paramètres d'entrée pour l'Action GitHub. Par exemple, vous pouvez activer le seuil a11y en utilisant enable_a11y_threshold: true. Une liste complète des paramètres d'entrée se trouve dans le README de l'Action GitHub de Axe Developer Hub .

note

You do not need to set the server_url parameter if you created your project on axe.deque.com. If your organization uses a regional instance, private cloud, or on-premises deployment of Axe Developer Hub, you must set server_url to the base URL of that instance (for example, https://axe-eu.deque.com).

Résultats

L'action GitHub définit plusieurs paramètres de sortie, y compris le nombre de problèmes d'accessibilité détectés, les problèmes résolus et les problèmes dépassant le seuil a11y.

Si vous n'avez pas activé le seuil a11y, l'Action GitHub échouera chaque fois qu'il y a plus de zéro erreur d'accessibilité. Si activé, seules les violations dépassant le seuil a11y feront échouer l'Action GitHub. En savoir plus sur l'utilisation du seuil a11y pour personnaliser Axe Developer Hub selon ce que votre organisation souhaite prioriser.

L'échec de l'Action GitHub attachera un commentaire similaire à celui ci-dessous à votre pull request et peut bloquer la fusion.

Un message exemple que l'action GitHub attache à une requête de pull lorsqu'il a trouvé des erreurs d'accessibilité.

Cliquez sur le lien dans le commentaire de pull request pour consulter les informations sur les défauts d'accessibilité pour ce commit dans Axe Developer Hub.

Dépannage

Vous pourriez recevoir une erreur telle que la suivante :

Error: Resource not accessible by integration

Vérifiez que vous avez les autorisations nécessaires dans la page des paramètres pour les actions. Vous avez besoin des autorisations de lecture et écriture pour permettre à l'action d'ajouter des commentaires aux pull requests. Pour plus de granularité, vous pouvez choisir d'utiliser un GITHUB_TOKEN différent pour l'action GitHub. Ajoutez cette valeur au paramètre d'entrée github_token.

Exemple de workflow

Si vous n'avez pas déjà un workflow qui exécute votre suite de tests, vous pouvez utiliser l'exemple de workflow comme point de départ pour créer votre propre exécuteur de tests.

Le flux de travail d'exemple s'appelle Tests (tests.yml) et s'exécute sur n'importe quel commit ou pull request. Le travail qui exécute la suite de tests modifiée, cypress, montre comment exécuter une suite de tests Cypress. Le travail suivant dans l'exemple, axe-dev-hub, est une invocation de l'action GitHub Axe Developer Hub.

Le travail de votre suite de tests doit toujours s'exécuter avant l'action GitHub Axe Developer Hub.

tip

Le répertoire exemple contient un projet de test complet avec lequel vous pouvez expérimenter.

Références

Is this page helpful?

Help us improve this page

Still need help?