Testen von Seiten mit CLI

Bei Verwendung des URI-Eingabemodus des CLI stehen mehrere zusätzliche Optionen zur Verfügung, um den Umfang und die Regelsammlung eines Tests zu ändern. Zum Beispiel wird der folgende Code den Header und Footer von einem Test ausschließen und die Regel zur Farbkontraste deaktivieren:

axe http://example.com --exclude footer,header --disable color-contrast

Optionen

-a, --axe-source <path>

Pfad zu einer alternativen axe.js Datei. Die meisten Benutzer benötigen diese Option nicht. Sie ist für fortgeschrittene Anwendungsfälle gedacht, wie z. B. Tests gegen eine bestimmte oder gepatchte Version von axe-core.

--axe-devhub-api-key <your-API-key>

Geben Sie den Axe Account API-Schlüssel an, um Barrierefreiheitsergebnisse an Axe Developer Hub zu senden. Die Ergebnisse werden dem Projekt zugeordnet, das mit der angegebenen Projekt-ID verknüpft ist (angegeben mit der --axe-devhub-project-id Befehlszeilenoption) nachdem der Test abgeschlossen ist. Sowohl --axe-devhub-api-key als auch --axe-devhub-project-id sind erforderlich, um Ergebnisse an Axe Developer Hub zu senden. Siehe Verwendung des CLI zum Senden von Barrierefreiheitsergebnissen an Axe Developer Hub für weitere Informationen.

--axe-devhub-project-id <your-project-ID>

Geben Sie die Axe Developer Hub-Projekt-ID an, um Ergebnisse von Barrierefreiheitstests zu erhalten. Sowohl --axe-devhub-api-key als auch --axe-devhub-project-id sind erforderlich, um Ergebnisse an Axe Developer Hub zu senden. Siehe Verwendung des CLI zum Senden von Barrierefreiheitsergebnissen an Axe Developer Hub für weitere Informationen.

--axe-devhub-server-url <url>

Geben Sie die URL des Axe Developer Hub-Servers an. Standard: https://axe.deque.com. Entspricht der AXE_DEVHUB_SERVER_URL Umgebungsvariable. Siehe Verwendung des CLI zum Senden von Barrierefreiheitsergebnissen an Axe Developer Hub für weitere Informationen.

-c, --custom <path>

Geben Sie eine benutzerdefinierte Regelsammlung an. Siehe Benutzerdefinierte Regelsammlungen für Details zur Erstellung einer Regelsammlungsdatei.

--chrome-options [options]

Kommagetrennte Liste von Chrome-Befehlszeilenschaltern, die an den Browser übergeben werden sollen. Zum Beispiel:

axe http://example.com --chrome-options="some-switch,some-other-switch"

--chrome-path <path>

Absoluter Pfad zur ausführbaren Datei des Chrome-Browsers. Verwenden Sie dies, um axe auf eine bestimmte Chrome-Installation zu verweisen, wenn der Standardbrowser nicht gefunden werden kann, oder Sie müssen gegen eine bestimmte Version testen.

--chromedriver-path <path>

Absoluter Pfad zur ausführbaren Datei von ChromeDriver. ChromeDriver ist eine separate Binärdatei vom Chrome-Browser selbst; es fungiert als Brücke, die axeWebDriver-Befehle in Anweisungen übersetzt, die Chrome ausführen kann.

-d, --dir <path>

Das Verzeichnis, in dem die JSON-Ergebnisdatei gespeichert wird. Ohne diese Option (oder --save oder --report) wird keine Datei geschrieben und die Ergebnisse werden statt dessen als menschenlesbare Zusammenfassung im Terminal ausgegeben. Siehe auch -j, --stdout , wenn Sie maschinenlesbare Ausgaben benötigen, ohne auf die Festplatte zu schreiben.

-l, --disable <list>

Kommagetrennte Liste von Regel-IDs, die deaktiviert werden sollen. Siehe die axe-core Regelbeschreibungen für eine vollständige Liste der Regel-IDs.

axe http://example.com --disable color-contrast,duplicate-id

-e, --exclude <list>

Kommagetrennte Liste von CSS-Selektoren für Elemente, die vom Test ausgeschlossen werden sollen. Zum Beispiel:

# Exclude by element type
axe http://example.com --exclude footer,header

# Exclude by class or ID
axe http://example.com --exclude ".ad-banner,#cookie-notice"

# Exclude by attribute
axe http://example.com --exclude "[aria-hidden=true]"

-f, --format <value>

Format des generierten Berichts. Erfordert -r, --report. Siehe Erstellen und Filtern von Berichten für Details darüber, was jedes Format enthält. Standard: html.

axe http://example.com --report ./reports --format html+junit+csv

--filter <list>

Kommagetrennte Liste von Ergebnistypen, die in die CSV-Ausgabe einbezogen werden sollen. Es werden nur die angegebenen Typen angezeigt; alle anderen sind ausgeschlossen. Gültige Werte sind passes, violations, incomplete, und inapplicable. Erfordert --format csv.

axe reporter ./axe-reports/json/ --format=csv --filter passes,inapplicable

-i, --include <list>

Kommagetrennte Liste von CSS-Selektoren. Wenn angegeben, testet axe nur die übereinstimmenden Elemente, und alles andere auf der Seite wird ignoriert. Dies ist sehr einschränkend, und die meisten Benutzer sollten stattdessen verwenden. Verwenden Sie -e, --exclude nur, wenn Sie das Testen auf eine bestimmte Komponente isolieren möchten, z. B. während des gezielten Debuggings oder bei komponentenbezogenen CI-Überprüfungen. --include Schreiben Sie die vollständigen Ergebnisse als maschinenlesbares JSON in stdout anstelle der menschenlesbaren Terminalzusammenfassung. Alle anderen Ausgaben werden unterdrückt. Verwenden Sie dies, wenn Sie Ergebnisse an ein anderes Programm weiterleiten.

# Test only the main navigation
axe http://example.com --include nav

# Test only elements with a specific class or ID
axe http://example.com --include ".my-widget,#signup-form"

# Test only elements with a specific attribute
axe http://example.com --include "[data-testid=checkout]"

-j, --stdout

Legen Sie fest, wie viel Zeit (Millisekunden)

--load-delay <n>

nach dem Laden der Seite wartet, bevor der Audit durchgeführt wird (Standard: 0). axe Berichten Sie keine Git-Branch- und Commit-Informationen, wenn Sie Ergebnisse an Axe Developer Hub senden. Siehe

--no-git-data

Verwendung der CLI, um Barrierefreiheitsergebnisse an Axe Developer Hub zu senden .Unterdrückt die Ausgabe der Zusammenfassung von Verstößen (Regel-IDs, Anzahl, betroffene Selektoren und Hilfe-URLs), ohne alles zu unterdrücken. Fortschrittsmeldungen und Ergebnisse, die über

--no-reporter

, --save, oder --dirgeschrieben werden, bleiben unberührt. Hauptsächlich nützlich in CI-Pipelines, in denen Sie Ergebnisse in einer Datei speichern und --report für das Pass/Fail-Signalisieren verwenden und keine ausführlichen Details zu Verstößen im Build-Log möchten. Für vollständige Stille mit JSON-Ergebnissen verwenden Sie --exit stattdessen. -j, --stdout Beenden Sie mit

-q, --exit

Fehlercode, wenn irgendein Barrierefreiheitstest fehlschlägt. 1 Das Verzeichnis, in dem der formatierte Bericht geschrieben wird. Funktioniert mit

-r, --report <output-dir>

, um das Ausgabeformat zu steuern (standardmäßig HTML). Verwenden Sie dies, wenn Sie einen menschen- oder maschinenlesbaren Bericht anstelle von rohem JSON wünschen, z. B. einen HTML-Bericht zum Teilen mit Stakeholdern oder eine JUnit-XML-Datei zur CI-Integration. Für rohe JSON-Ausgabe verwenden Sie -f, --format stattdessen. -d, --dir Kommagetrennte Liste von Regel-IDs, die ausgeführt werden sollen. Nur die angegebenen Regeln werden überprüft; alle anderen werden übersprungen. Siehe die

--rules <list>

Beschreibung der axe-core-Regeln für eine vollständige Liste der Regel-IDs. Speichern Sie die Ergebnisse als JSON-Datei im aktuellen Verzeichnis. Der Dateiname ist optional; wenn er weggelassen wird, erhält die Datei den Namen

axe http://example.com --rules color-contrast,duplicate-id

-s, --save [filename]

. Um stattdessen in ein spezifisches Verzeichnis zu speichern, verwenden Sie axe-result.json. -d, --dirWenn

--show-errors

auf einen Laufzeitfehler stößt (wie das Scheitern der Initialisierung oder eine Ausnahme während der Ausführung), wird normalerweise eine kurze Fehlermeldung an stderr ausgegeben. Dieses Flag fügt der Ausgabe den vollständigen Stack-Trace hinzu. Es beeinflusst nicht, wie Barrierefreiheitsverletzungen gemeldet werden. Verwenden Sie dies beim Debuggen einer benutzerdefinierten axe Datei, beim Diagnostizieren unerwarteter Fehler in CI oder beim Sammeln von Informationen für einen Fehlerbericht. --axe-source Kommagetrennte Liste von Tags, um zu filtern, welche Regeln ausgeführt werden. Nur Regeln, die mindestens einem der angegebenen Tags entsprechen, werden eingeschlossen. Siehe die

-t, --tags <list>

Dokumentation zu axe-core-Tags für eine vollständige Liste der verfügbaren Tags. Druckt drei Zeitmessungen auf das Terminal nach jedem Testlauf:

axe http://example.com --tags wcag2a,wcag2aa

--timer

Ladezeit der Seite durch axe

• : wie lange die Seite im Browser zum Laden benötigteAusführungszeit von axe-core
• : wie lange axe-core zur Analyse der Seite benötigteGesamte Testzeit
• : Gesamtzeit für den LaufVerwenden Sie dies zur Diagnose langsamer Tests. Beispielsweise können Sie mit dieser Option feststellen, ob die Zeit mit dem Warten auf das Laden der Seite oder in der Axe-Analyse verbracht wird oder warum ein Lauf auf

oder --page-timeout Grenzwerte stößt. --script-timeout limits.

-v, --verbose

Wenn Verstöße festgestellt werden, wird nach der Zusammenfassung der Verstöße ein JSON-Block ausgegeben, der Folgendes enthält:

• **Prüf-Engine**: die verwendete axe-core-Version
• **Prüf-Umgebung**: Browser-User-Agent, Viewport-Breite und -Höhe sowie Bildschirmorientierung
• **Testläufer**: der Name des Runners

Beachten Sie, dass diese Ausgabe nur erscheint, wenn Verstöße erkannt werden. Hat eine Seite keine Verstöße, wird die Metadaten nicht ausgegeben. Verwenden Sie dies, wenn Sie genau bestätigen möchten, welche axe-core-Version verwendet wurde, Viewporteinstellungen überprüfen oder Umgebungsdetails in einem Fehlerbericht aufnehmen möchten.

Konfigurationsoptionen

Die folgenden Optionen steuern das Verhalten des Browsers und das Timing der Tests. Im Gegensatz zu den oben genannten Optionen bleiben diese zwischen CLI-Ausführungen bestehen; einmal eingestellt, wird der Wert in einer Voreinstellungsdatei gespeichert, die für alle zukünftigen Läufe verwendet wird. Sie können auch interaktiv eingestellt werden mit axe config-selenium.

Für vollständige Details siehe Konfigurationsoptionen.