Verwenden der axe DevTools Linter GitHub Action

In diesem Artikel erfahren Sie, wie Sie mit der GitHub-Aktion „axe DevTools Linter“ von Deque Ihren Code beim Erstellen einer GitHub-Pull-Anfrage auf Zugänglichkeitsfehler überprüfen. Nachdem die Aktion ausgeführt wurde, enthält die Pull-Anfrage Kommentare, die die Zugänglichkeitsfehler in den übermittelten Dateien zeigen.

Die folgenden Abschnitte zeigen die Schritte zum Einrichten dieser GitHub-Aktion mit Ihrem Repo.

Step 1: Obtain an API Key (SaaS Only)

Für axe DevTools Linter SaaS müssen Sie einen API-Schlüssel erhalten. Sie können einen erhalten, indem Sie die Schritte unter Erhalten eines axe DevTools Linter SaaS-API-Schlüssels befolgen, oder Sie können einen vorhandenen API-Schlüssel von der Einstellungsseite für Ihr axe-Konto verwenden. Wenn Sie Probleme beim Abrufen eines API-Schlüssels haben, wenden Sie sich an den Helpdesk von Deque(mailto:help@deque.com).

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

Wenn Sie axe DevTools Linter SaaS verwenden, müssen Sie Ihren API-Schlüssel zu den Geheimnissen Ihres Repositorys hinzufügen. Dies können Sie tun, indem Sie auf GitHub auf die Einstellungsseite Ihres Repositorys gehen. In den GitHub-Dokumenten finden Sie weitere Informationen unter Erstellen verschlüsselter Geheimnisse für ein Repository .

Für den Beispiel-Workflow im nächsten Schritt sollten die Geheimnisse wie folgt heißen:

• AXE_LINTER_API_KEY für den API-Schlüssel

Schritt 3: Erstellen Sie den Workflow

Als Nächstes müssen Sie einen Workflow erstellen, um Ihre Dateien auf Barrierefreiheitsfehler zu überprüfen. Sie können eine Datei mit dem Namen axe-linter.yml im Verzeichnis .github/workflows Ihres Repositorys erstellen.

Sie können diese Datei online als neuen Workflow unter der Registerkarte Aktionen auf der Webseite Ihres Repositorys erstellen (klicken Sie im Abschnitt GitHub Actions Erste Schritte oben auf der Seite Aktionen auf Richten Sie selbst einen Workflow ein ) oder sie lokal erstellen und in Ihr Repository übertragen.

Die axe-linter-Aktion wird im Workflow aufgerufen, wenn eine Pull-Anfrage erstellt wird (on: [pull_request]). Der Workflow verwendet zwei Abhängigkeiten:

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

Die folgenden Abschnitte zeigen Beispiele für .github/workflows/axe-linter.yml, die Sie für SaaS- oder On-Premise-Versionen von axe DevTools Linter verwenden können:

Für SaaS

Die SaaS-Version des Workflows enthält den Parameter api_key , jedoch nicht den Parameter 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 }}

Für On-Prem

Die lokale Version des Workflows enthält den Parameter axe_linter_url , jedoch nicht den Parameter 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

Der Wert für axe_linter_url wird in diesem Beispiel aus der Shell-Umgebung als AXE_LINTER_URL gelesen.

Für die lokale Version von axe DevTools Linter benötigen Sie keinen API-Schlüssel, aber Ihre Instanz von axe DevTools Linter muss über eine Netzwerkverbindung für GitHub-Workflows erreichbar sein.

GitHub-Aktionsparameter

Die Aktion „dequelabs/axe-linter“ verwendet die folgenden Parameter (in den obigen Beispielen in der Klausel mit angegeben):

Ergebnisse des Workflows

Der folgende Screenshot zeigt das Ergebnis der Erstellung einer Pull-Anfrage mit einer Datei, die einen Zugänglichkeitsfehler aufweist. Die Datei bad-file.md enthält Überschriftenebenen, die von Überschriftenebene 1 bis Überschriftenebene 3 reichen und Ebene 2 überspringen, was einen Zugänglichkeitsfehler darstellt.

Fehlerbehebung

Das Debuggen von Problemen mit GitHub-Aktionen kann eine Herausforderung sein, da die Fehlermeldungen das zugrunde liegende Problem häufig nicht genau wiedergeben. Dieser Abschnitt enthält einige Beispiele für Fehler, die möglicherweise auftreten.

Incorrectly Named Secret (SaaS Only)

Wenn der Name, den Sie Ihrem geheimen API-Schlüssel geben, nicht mit dem Namen im Workflow übereinstimmt, erhalten Sie möglicherweise eine Fehlermeldung über einen fehlenden Befehl statt einer Fehlermeldung, dass der Schlüssel nicht definiert ist:

... line 41: Missing: command not found

Berechtigungsfehler

Bei GitHub-Aktionen kann es an vielen Stellen zu falschen Berechtigungen kommen. Wenn Sie beispielsweise mit einer uses -Klausel auf ein Repository verweisen, das nicht öffentlich ist, erhalten Sie häufig die Fehlermeldung, dass das Repository nicht gefunden wurde, anstatt dass Sie keinen Zugriff darauf haben:

fatal: repository 'name' not found

Von der Aktion überprüfte Dateien

Dateien mit diesen Erweiterungen werden auf Zugänglichkeitsfehler überprüft:

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

Nächster Schritt

Informationen zu den von axe DevTools Linter zum Überprüfen Ihres Codes verwendeten Regeln finden Sie unter Barrierefreiheitsregeln. Weitere Informationen dazu, wie Sie verhindern können, dass Dateien mit Barrierefreiheitsfehlern in Git festgeschrieben werden, finden Sie unter Verwenden eines Git-Pre-Commit-Hooks.