Utilisation de l'axe DevTools Linter GitHub Action

Link to Utilisation de l'axe DevTools Linter GitHub Action copied to clipboard

Comment utiliser l'action axe DevTools Linter GitHub pour vérifier les erreurs d'accessibilité dans les pull requests

Free Trial
Not for use with personal data

Cet article vous montre comment utiliser l'action GitHub axe DevTools Linter de Deque pour vérifier votre code pour les erreurs d'accessibilité lors de la création d'une pull request GitHub. Une fois l’action exécutée, la demande d’extraction contiendra des commentaires indiquant les erreurs d’accessibilité dans les fichiers validés.

Les sections suivantes montrent les étapes à suivre pour configurer cette action GitHub avec votre dépôt.

note

Plusieurs étapes ne sont nécessaires que si vous utilisez la version SaaS d'axe DevTools Linter. Par conséquent, si vous utilisez la version sur site, vous pouvez ignorer les étapes identifiées comme SaaS uniquement.

Step 1: Obtain an API Key (SaaS Only)

Pour axe DevTools Linter SaaS, vous devez obtenir une clé API. Vous pouvez en obtenir une en suivant les étapes décrites dans Obtention d'une clé API SaaS axe DevTools Linter, ou vous pouvez utiliser une clé API existante à partir de la page des paramètres pour votre compte axe DevTools. Si vous rencontrez des problèmes pour obtenir une clé API, contactez le service d'assistance de Deque.

Step 2: Create a Repository Secret for Your API Key (SaaS Only)

Si vous utilisez axe DevTools Linter SaaS, vous devez ajouter votre clé API aux secrets de votre référentiel, ce que vous pouvez faire en accédant à la page Paramètres de votre référentiel sur GitHub. Pour plus d'informations, consultez Création de secrets chiffrés pour un référentiel sur GitHub Docs.

Pour l'exemple de workflow de l'étape suivante, les secrets doivent être appelés :

  • pour la clé API - AXE_LINTER_API_KEY

Étape 3 : Créer le flux de travail

Ensuite, vous devez créer un flux de travail pour vérifier vos fichiers en quête d'erreurs d'accessibilité. Vous pouvez créer un fichier nommé axe-linter.yml dans le répertoire .github/workflows de votre dépôt.

Vous pouvez créer ce fichier en ligne en tant que nouveau flux de travail sous l'onglet Actions sur la page Web de votre répertoire (cliquez sur mettre en place un flux de travail vous-même sous la section Commencer avec les actions GitHub en haut de la page Actions ) ou le créer localement et le valider dans votre répertoire.

tip

La version la plus récente du workflow YAML se trouve dans le fichier README.md dans le référentiel GitHub Action.

L'action axe-linter est invoquée dans le workflow lorsqu'une demande d'extraction est créée (on: [pull_request]). Le workflow utilise deux dépendances :

  • actions/checkout@v4
  • dequelabs/axe-linter-action@v1

Les sections suivantes présentent des exemples de .github/workflows/axe-linter.yml que vous pouvez utiliser pour les versions SaaS ou sur site d'axe DevTools Linter :

Pour SaaS

La version SaaS du workflow inclut le paramètre api_key mais n'inclut pas le paramètre axe_linter_url :

name: Linting for accessibility issues

on: [pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - uses: dequelabs/axe-linter-action@v1
        with:
          api_key: ${{ secrets.AXE_LINTER_API_KEY }}          github_token: ${{ secrets.GITHUB_TOKEN }}

Pour sur site

La version sur site du workflow inclut le paramètre axe_linter_url mais n'inclut pas le paramètre api_key  :

name: Linting for accessibility issues

on: [pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - uses: dequelabs/axe-linter-action@v1
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          axe_linter_url: $AXE_LINTER_URL

La valeur de axe_linter_url est lue dans cet exemple à partir de l'environnement shell sous le nom AXE_LINTER_URL.

Pour la version sur site d'axe DevTools Linter, vous n'avez pas besoin d'une clé API, mais votre instance d'axe DevTools Linter doit être accessible aux workflows GitHub via une connexion réseau.

Paramètres de l'Action GitHub

L'action dequelabs/axe-linter utilise les paramètres suivants (spécifiés dans les exemples ci-dessus dans la clause avec ) :

Nom Description
github_token Requis pour l'authentification. Généralement défini par le secret prédéfini GITHUB_TOKEN. Voir Identification automatique des jetons sur la documentation GitHub.
api_key (SaaS uniquement) Pour axe DevTools Linter SaaS, une clé API est requise pour autoriser votre workflow. La clé est obtenue à partir du secret AXE_LINTER_API_KEY que vous avez créé à l’étape 2.
axe_linter_url (Facultatif pour SaaS, requis pour sur site) Ce paramètre vous permet de spécifier un serveur différent à utiliser pour le linting. La plupart des utilisateurs qui utilisent la version SaaS n'auront pas besoin de ce paramètre car ils utiliseront les serveurs de Deque pour le linting. Cependant, les utilisateurs de la version sur site devront spécifier ce paramètre. Vous devez spécifier http: ou https: comme protocole, et à moins que vous n'utilisiez le port standard http: (80) ou https: (443) et le redirigiez vers le port 3000, vous devez également spécifier le port. Par exemple : http://example.com:3000.

Résultats de Workflow

La capture d’écran suivante montre le résultat de la création d’une demande d’extraction avec un fichier présentant une erreur d’accessibilité. Le fichier, bad-file.md, contient des niveaux de titre qui vont du niveau de titre 1 au niveau de titre 3, en sautant le niveau 2, ce qui constitue une erreur d'accessibilité.

Une "pull request" sur GitHub et l'erreur signalée par l'action GitHub axe DevTools Linter. Le fichier sur le côté droit de l'image contient une erreur d'accessibilité où les titres sautent le niveau 2. Il y a une alerte d'erreur de l'action GitHub fournissant des détails sur l'erreur.](../images/screen-gha-in-action.png)

Dépannage

Le débogage des problèmes liés aux actions GitHub peut être difficile, car les messages d’erreur ne parviennent souvent pas à représenter avec précision le problème sous-jacent. Cette section contient quelques exemples d’erreurs que vous pourriez voir.

Incorrectly Named Secret (SaaS Only)

Si le nom que vous donnez à votre clé secrète API ne correspond pas au nom dans le workflow, vous pouvez recevoir des erreurs concernant une commande manquante plutôt qu'une erreur indiquant que la clé n'est pas définie :

... line 41: Missing: command not found

Erreurs d'autorisations

Il existe de nombreux endroits avec les actions GitHub où les autorisations peuvent être incorrectes. Par exemple, si vous référencez un dépôt qui n'est pas public avec une clause uses , vous recevrez souvent l'erreur indiquant que le dépôt n'a pas été trouvé au lieu de vous n'avez pas accès à celui-ci :

fatal: repository 'name' not found

Fichiers vérifiés par l'action

Les fichiers avec ces extensions seront vérifiés pour détecter les erreurs d'accessibilité :

  • .js
  • .jsx
  • .tsx
  • .html
  • .vue
  • .md
  • .markdown

Prochaines étapes

Pour plus d'informations sur les règles utilisées par axe DevTools Linter pour vérifier votre code, consultez Règles d'accessibilité. Si vous souhaitez en savoir plus sur la manière d'empêcher la validation de fichiers contenant des erreurs d'accessibilité dans Git, consultez Utilisation d'un Git Pre-Commit-Hook.