Axe DevTools für Web-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

Ein Kommandozeilenwerkzeug zur Automatisierung von Web-Barrierefreiheitsprüfungen ohne Testcode zu schreiben.

Not for use with personal data

Axe DevTools für Web CLI ist ein Befehlszeilen-Tool, das Barrierefreiheitsanalysen auf Webseiten durchführt und Berichte erstellt. Es ist für Teams gedacht, die Barrierefreiheitstests automatisieren möchten, ohne Axe DevTools in ein bestehendes Testframework zu integrieren, beispielsweise als Schritt in einer CI/CD-Pipeline, oder wenn Axe DevTools APIs für Ihre Sprache nicht verfügbar sind.

Wie es funktioniert

Jede axe-Analyse erzeugt JSON-Ergebnisdateien, eine pro analysierten Seitenstatus. Diese Dateien werden beim Testen erzeugt und beim Berichten oder Hochladen von Ergebnissen verwendet.

Der typische Arbeitsablauf hat zwei Phasen:

  1. Seiten analysieren: Eine oder mehrere URLs durch axe laufen lassen und JSON-Ergebnisse speichern:

    axe <url>              → test a URL directly
axe spec <spec-file>   → test pages and workflows defined in a YAML/JSON file
axe bulk-spec <dir>    → test using all spec files in a directory

  2. Mit Ergebnissen etwas tun: konvertieren, hochladen oder anderweitig senden:

    axe reporter <results>     → generate HTML, JUnit XML, or CSV reports
axe bulk-reports <results> → upload to the Axe Reports service
axe devhub <results>       → send to Axe Developer Hub

Die Befehle axe und axe spec unterstützen auch --format und --report Flags, um Berichte in einem Schritt zu erzeugen, ohne einen separaten axe reporter-Aufruf.

Benutzerdefinierte Elemente und ElementInternals

Ab Version 4.13.0 lesen Scans die ARIA-Semantik, die Webkomponenten in JavaScript über ElementInternals deklarieren, anstatt nur die im Markup vorhandenen role- und aria-*-Attribute. Es ist keine Konfiguration oder Befehlszeilenoption erforderlich. Ihre Komponenten müssen ihre Interna veröffentlichen, damit dies wirksam wird, und eine Komponente, die sie in einem privaten Klassenfeld speichert, kann nicht gelesen werden. Siehe Testen von benutzerdefinierten Elementen, die ElementInternals verwenden.

Befehle

Befehl Zweck
axe <url...> Analysieren Sie eine oder mehrere URLs direkt. Standardbrowser: Firefox. Standardregelsatz: WCAG 2.1 AA.
axe spec <spec-file> Analysieren Sie Seiten, die in einer YAML- oder JSON-Spezifikationsdatei definiert sind, einschließlich mehrstufiger Workflows.
axe bulk-spec <dir> Führen Sie alle Spezifikationsdateien in einem Verzeichnis und seinen Unterverzeichnissen aus.
axe reporter <results-dir> Konvertieren Sie JSON-Ergebnisse in HTML-, JUnit-XML- oder CSV-Berichte.
axe bulk-reports <results-dir> Laden Sie JSON-Ergebnisse in den Axe Reports-Dienst hoch.
axe devhub <results-dir> Senden Sie JSON-Ergebnisse an den Axe Developer Hub.
axe ruleset Listen, validieren oder verwalten Sie benutzerdefinierte Regelsätze.
axe config-selenium Sehen Sie sich die Standardbrowser-/Selenium-Einstellungen an oder aktualisieren Sie diese.

JSON-Ergebnisse

Wenn Sie axe spec ausführen oder axe <url> --save verwenden, werden die Ergebnisse als JSON-Dateien im Ausgabeverzeichnis gespeichert. Jede Datei erfasst die vollständige axe-Analyse für einen einzelnen Seitenstatus: Verstöße, bestandene Prüfungen, unvollständige Prüfungen und nicht anwendbare Regeln, zusammen mit Metadaten wie der URL, dem Browser und dem Zeitstempel.

Ergebnisdateien werden nach Projekt geordnet und nach der Seite benannt, die getestet wird:

<output-dir>/<project-id>/<project-id>-<page-id>[-<analyze-title>].json

Diese Dateien werden von axe reporter, axe bulk-reports und axe devhub verwendet. Für Details zu Dateinamen und Verzeichnisstruktur siehe Berichte erstellen.

Das JSON-Ergebnisschema wird durch axe-core definiert. Für eine vollständige Referenz siehe axe-core API-Dokumentation.

In diesem Abschnitt

Is this page helpful?

Help us improve this page

Still need help?