Testen von Seiten mit der CLI

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

Optionen zum Testen einzelner Webseiten mit dem Axe DevTools für Web CLI

Not for use with personal data

Wenn der URI-Eingabemodus der CLI verwendet wird, stehen mehrere zusätzliche Optionen zur Verfügung, um den Umfang und das Regelset 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 das Testen einer spezifischen oder gepatchten Version von axe-core.

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

Geben Sie den API-Schlüssel des Axe-Kontos an, um die Barrierefreiheitsergebnisse an den Axe Developer Hub zu senden. Die Ergebnisse werden an das Projekt gesendet, das mit der angegebenen Projekt-ID (angegeben mit der --axe-devhub-project-id-Befehlszeilenoption) verknüpft ist, nachdem die Tests abgeschlossen sind. Sowohl --axe-devhub-api-key als auch --axe-devhub-project-id sind erforderlich, um Ergebnisse an den Axe Developer Hub zu senden. Weitere Informationen finden Sie unter Unterdrückt die Ausgabe der Verletzungszusammenfassung (Regel-IDs, Anzahlen, betroffene Selektoren und Hilfe-URLs), ohne alles zu unterdrücken. Fortschrittsmeldungen und Ergebnisse, die über.

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

Geben Sie die Projekt-ID des Axe Developer Hub an, um Ergebnisse von Barrierefreiheitstests zu empfangen. Sowohl --axe-devhub-api-key als auch --axe-devhub-project-id sind erforderlich, um Ergebnisse an den Axe Developer Hub zu senden. Weitere Informationen finden Sie unter Unterdrückt die Ausgabe der Verletzungszusammenfassung (Regel-IDs, Anzahlen, betroffene Selektoren und Hilfe-URLs), ohne alles zu unterdrücken. Fortschrittsmeldungen und Ergebnisse, die über.

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

Geben Sie die URL des Servers des Axe Developer Hub an. Standardwert: https://axe.deque.com. Entspricht der AXE_DEVHUB_SERVER_URL-Umgebungsvariable. Weitere Informationen finden Sie unter Unterdrückt die Ausgabe der Verletzungszusammenfassung (Regel-IDs, Anzahlen, betroffene Selektoren und Hilfe-URLs), ohne alles zu unterdrücken. Fortschrittsmeldungen und Ergebnisse, die über.

-c, --custom <path>

Geben Sie ein benutzerdefiniertes Regelsatz an, der verwendet werden soll. Siehe Benutzerdefinierte Regelsets für Details zur Erstellung einer Regelsatz-Datei.

--chrome-options [options]

Kommagetrennte Liste von Chrome-Befehlszeilen-Schaltern, 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 Chrome-Browser ausführbaren Datei. Verwenden Sie dies, um axe auf eine spezifische Chrome-Installation zu verweisen, wenn der Standardbrowser nicht gefunden werden kann oder Sie eine bestimmte Version verwenden müssen.

--chromedriver-path <path>

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

-d, --dir <path>

Das Verzeichnis, in dem die JSON-Ergebnisdatei gespeichert wird. Ohne dieses Flag (oder --save oder --report) wird keine Datei geschrieben, und die Ergebnisse werden als menschenlesbare Zusammenfassung im Terminal ausgegeben. Siehe auch -j, --stdout, wenn Sie eine maschinenlesbare Ausgabe ohne Schreiben auf die Festplatte benötigen.

-l, --disable <list>

Durch Kommas getrennte Liste von Regel-IDs zum Deaktivieren. Siehe Speichern Sie die Ergebnisse als JSON-Datei im aktuellen Verzeichnis. Der Dateiname ist optional; wenn ausgelassen, wird die Datei benannt 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 von Tests 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. Einzelheiten dazu, was jedes Format enthält, finden Sie unter Erstellen und Filtern von Berichten. Standard: html.

Wert Ausgabe
html HTML-Bericht
junit JUnit-XML-Bericht
csv CSV-Tabellenkalkulation
universal Axe Universal Format JSON-Datei
html+junit+csv Alle drei Formate gleichzeitig
axe http://example.com --report ./reports --format html+junit+csv

--filter <list>

Durch Kommas getrennte Liste von Ergebnisarten, die in die CSV-Ausgabe aufgenommen werden sollen. Nur die angegebenen Typen erscheinen; alle anderen werden 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>

Durch Kommas getrennte Liste von CSS-Selektoren. Wenn angegeben, testet axe die übereinstimmenden Elemente, und alles andere auf der Seite wird ignoriert. Dies ist sehr restriktiv, und die meisten Benutzer sollten stattdessen die passenden Elemente, und alles andere auf der Seite wird ignoriert. Dies ist sehr einschränkend, und die meisten Benutzer sollten stattdessen -e, --exclude verwenden. Verwenden Sie --include nur, wenn Sie Tests auf eine bestimmte Komponente isolieren möchten, z.B. während des fokussierten Debuggings oder bei CI-Überprüfungen auf Komponentenebene.

# 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) gewartet wird, nachdem die Seite geladen wurde, bevor die Prüfung gestartet wird (Standard: 0).

--load-delay <n>

Legen Sie fest, wie lange (in Millisekunden) axe nach dem Ladevorgang der Seite warten wird, bevor die Überprüfung gestartet wird (Standard: 0).

--no-git-data

Berichten Sie keine Git-Zweig- und Commit-Informationen, wenn Sie Ergebnisse an den Axe Developer Hub senden. Siehe Unterdrückt die Ausgabe der Verletzungszusammenfassung (Regel-IDs, Anzahlen, betroffene Selektoren und Hilfe-URLs), ohne alles zu unterdrücken. Fortschrittsmeldungen und Ergebnisse, die über.

--no-reporter

Unterdrückt die Ausgabe der Verletzungszusammenfassung (Regel-IDs, Anzahlen, betroffene Selektoren und Hilfs-URLs), ohne alles zum Schweigen zu bringen. Fortschrittsmeldungen und auf die Festplatte geschriebene Ergebnisse über --save, --dir oder --report sind nicht betroffen. Hauptsächlich nützlich in CI-Pipelines, in denen Sie Ergebnisse in einer Datei speichern und --exit für die Signalgebung von Pass/Fail verwenden und keine ausführlichen Verletzungsdetails im Build-Log wünschen. Für vollständige Stille mit JSON-Ergebnisausgabe, verwenden Sie stattdessen -j, --stdout.

-q, --exit

Beenden Sie mit 1-Fehlercode, wenn ein Barrierefreiheitstest fehlschlägt.

-r, --report <output-dir>

Das Verzeichnis, in dem der formatierte Bericht geschrieben wird. Funktioniert mit -f, --format, um das Ausgabeformat zu steuern (standardmäßig HTML). Verwenden Sie dies, wenn Sie einen menschenlesbaren oder maschinenlesbaren Bericht anstelle von rohem JSON wünschen, zum Beispiel einen HTML-Bericht zum Teilen mit Stakeholdern oder eine JUnit-XML-Datei zur CI-Integration. Für rohe JSON-Ausgabe, verwenden Sie stattdessen -d, --dir.

--rules <list>

Durch Kommas getrennte Liste von Regel-IDs, die ausgeführt werden sollen. Nur die angegebenen Regeln werden überprüft; alle anderen werden übersprungen. Siehe Speichern Sie die Ergebnisse als JSON-Datei im aktuellen Verzeichnis. Der Dateiname ist optional; wenn ausgelassen, wird die Datei benannt für eine vollständige Liste der Regel-IDs.

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

-s, --save [filename]

Speichern Sie die Ergebnisse als JSON-Datei im aktuellen Verzeichnis. Der Dateiname ist optional; wenn er weggelassen wird, heißt die Datei axe-result.json. Um stattdessen in einem bestimmten Verzeichnis zu speichern, verwenden Sie -d, --dir.

--show-errors

Wenn axe auf einen Laufzeitfehler trifft (wie z.B. ein Initialisierungsfehler oder eine während der Ausführung ausgelöste Ausnahme), gibt es normalerweise eine kurze Fehlermeldung an stderr aus. Dieses Flag fügt dieser Ausgabe den vollständigen Stack-Trace hinzu. Es beeinflusst nicht, wie Barriereverletzungen gemeldet werden. Verwenden Sie dies beim Debuggen einer benutzerdefinierten --axe-source-Datei, um unerwartete Fehler in CI zu diagnostizieren oder Informationen für einen Fehlerbericht zu sammeln.

-t, --tags <list>

Durch Kommas getrennte Liste von Tags, um zu filtern, welche Regeln ausgeführt werden. Nur Regeln, die mindestens einem der angegebenen Tags entsprechen, werden einbezogen. Siehe Druckt nach jedem Testlauf drei Zeitmessungen auf das Terminal: für eine vollständige Liste der verfügbaren Tags.

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

--timer

: wie lange das Laden der Seite im Browser gedauert hat

  • axe-core Ausführungszeit: wie lange das Laden der Seite im Browser dauerte
  • Gesamte Testzeit: wie lange axe-core benötigt hat, um die Seite zu analysieren
  • Verwenden Sie dies, um langsame Tests zu diagnostizieren. Verwenden Sie zum Beispiel diese Option, um festzustellen, ob die Zeit mit dem Warten auf das Laden der Seite oder in der Axe-Analyse verbracht wird, oder um zu untersuchen, warum ein Lauf auf: Gesamtzeit von Anfang bis Ende für den Lauf

Verwenden Sie dies, um langsame Tests zu diagnostizieren. Verwenden Sie diese Option beispielsweise, um festzustellen, ob die Zeit mit dem Warten auf das Laden der Seite oder in der Axe-Analyse verbracht wird, oder um zu untersuchen, warum ein Lauf auf --page-timeout- oder --script-timeout-Grenzen stößt.

--universal-best-practices

Erfasst bestPracticesEnabled=true in den Metadaten des universellen Formatoutputs. Erfordert --format universal.

--universal-ruleset <id>

Gibt die Regelsatz-ID an, die in den Metadaten des universellen Formatoutputs aufgezeichnet werden soll. Standardmäßig: wcag2.1. Erfordert --format universal.

Ruleset-ID Standard
wcag2 WCAG 2.0 AA
wcag2.1 WCAG 2.1 AA (Standard)
wcag2.2 WCAG 2.2 AA
wcag2aaa WCAG 2.0 AAA
wcag2.1aaa WCAG 2.1 AAA
wcag2.2aaa WCAG 2.2 AAA
508 Abschnitt 508
en301549 EN 301 549
ttv5 Trusted Tester v5
rgaav4 RGAA v4
note

Das 508-Regelsatz erfasst standard: "WCAG 2.1 AA" im Output, da das universelle Format keinen eigenen Section 508-Standardwert hat.

-v, --verbose

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

  • Test-Engine: die verwendete axe-core Version
  • Testumgebung: Browser-User-Agent, Ansichtsfensterbreite und -höhe und Bildschirmausrichtung
  • Test-Runner: der Name des Runners

Beachten Sie, dass dieser Ausgang nur angezeigt wird, wenn Verstöße festgestellt werden. Wenn eine Seite keine Verstöße aufweist, werden die Metadaten nicht gedruckt. Verwenden Sie dies, wenn Sie genau bestätigen müssen, welche axe-core Version ausgeführt wurde, die Ansichtsfenstereinstellungen überprüfen oder Umgebungsdetails in einem Fehlerbericht enthalten möchten.

Konfigurationsoptionen

Die folgenden Optionen steuern das Browserverhalten und das Timing von Tests. Im Gegensatz zu den obigen Optionen bleiben diese zwischen den CLI-Durchläufen bestehen; durch einmaliges Einstellen wird der Wert in einer Präferenzdatei gespeichert, die für alle zukünftigen Läufe verwendet wird. Sie können auch interaktiv mit axe config-selenium eingestellt werden.

Option Beschreibung
--accept-untrusted Akzeptiere nicht vertrauenswürdige SSL-Zertifikate.
--browser [browser-name] Browser zum Ausführen. Erfordert die Selenium WebDriver-Bindung für den gewählten Browser.
--headless Starten Sie den Browser im Headless-Modus (kein sichtbares Fenster).
--page-timeout [ms] Maximale Zeit, die auf den Seitenladeprozess gewartet wird. Standard: 60000.
--post-analyze-pause [ms] Pause zwischen dem Start der Seitenanalyse und der nächsten Aktion. Standard: 2000.
--post-get-pause [ms] Pause zwischen dem Seitenladeprozess und dem Start des Scans. Standard: 2000.
--post-script-pause [ms] Pause zwischen einer Skriptaktion und dem Start des Scans. Standard: 2000.
--remote-server [server-url] Verwenden Sie einen Remote-WebDriver-Server wie BrowserStack oder Sauce Labs.
--script-timeout [ms] Maximale Zeit, die für das Ausführen eines Skripts in einer Spec-Datei erlaubt ist. Standard: 60000.
--window-size <width,height> Festlegen der Ansichtsfenstergröße in Pixeln, z.B. --window-size=1280,800. Gilt auch im headless-Modus.

Für vollständige Details siehe Konfigurationsoptionen.