axe DevTools für Web Cucumber

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
Not for use with personal data

Das axe-devtools-cucumber Gem bietet benutzerdefinierte Schrittdefinitionen, um zu bewerten, ob eine bestimmte Seite axe clean ist.

Dieses Gem erweitert die Schritte aus der Readme-Datei zum Gem „axe-core-cucumber“.

Einrichtung und Nutzung

Stellen Sie sicher, dass Sie Zugriff auf [Deque's Register][Attest NPM-Register Setup] haben. Wenn nicht, [verweisen Sie auf die Einrichtung][].

– Fügen Sie axe-devtools-cucumber [Befehl] zu Ihrer Gemfile- oder Gemspec-Datei hinzu und führen Sie bundle install[Befehl] aus.

gem "axe-devtools-cucumber"
spec.add_dependency "axe-devtools-cucumber"
  • Erfordert die vom Gem angebotenen Schrittdefinitionen. Normalerweise können Sie dies tun, indem Sie eine vorhandene Cucumber-Setup-Datei unter features/support/env.rb ergänzen.
require 'axe-cucumber-steps'
  • Verwenden Sie es mit dem WebDriver Ihrer Wahl.

API

Schritt - axe Clean sein (be axe clean)

Der Schritt be axe clean ist die Kernkomponente der Integration. Dies ist ein eigenständiger Schritt, der überprüft, ob die aktuell geladene Seite mit der Standardkonfiguration von axe.run axe clean ist (das gesamte Dokument wird mit den Standardregeln überprüft).

Then the page should be axe clean

Schritt – Auf Barrierefreiheit geprüft werden (be audited for accessibility)

Mit diesem Schritt können Sie die Barrierefreiheit Ihrer Site prüfen, ohne dass die Testsuite fehlschlägt. Für identifizierte violations konvertieren die Matcher das Testbeispiel in pending und geben die detaillierten Verstöße aus.

Then the page should be audited for accessibility [including]
[excluding] [according to/according to ruleset] [checking rules/checking-only-rules]
[skipping rules] [logging results for]

Klauseln

Klauseln sind verkettbare Methoden für die be axe clean und be audited for accessibility Schrittanweisungen.

Konfigurierbare Klauseln ermöglichen eine größere Granularität bei Tests und Erwartungen.

within- Einschlussklausel

Die Einschlussklausel (within "#selector") gibt an, welche Elemente der Seite überprüft werden sollen. Ein gültiger [CSS Selector][css selector] muss angegeben und in Anführungszeichen eingeschlossen werden. Zusammengesetzte Selektoren können beispielsweise zum Auswählen mehrerer Elemente verwendet werden within "#header, .footer". Weitere Informationen finden Sie in der Kontextparameterdokumentation.

Then the page should be axe clean within "#selector"
excluding- Ausschlussklausel

Die Ausschlussklausel (excluding "#selector") gibt an, welche Elemente des Dokuments ignoriert werden sollen. Ein gültiger [CSS Selector][css selector] muss angegeben und in Anführungszeichen eingeschlossen werden. Zum Auswählen mehrerer Elemente können zusammengesetzte Selektoren verwendet werden, zum Beispiel excluding "#widget, .ad". Weitere Informationen finden Sie in der Kontextparameterdokumentation.

Then the page should be audited for accessibility excluding "#selector"

Falls gewünscht, kann ein Semikolon (;) oder das Wort but verwendet werden, um die Ausschlussklausel von der Einschlussklausel (sofern vorhanden) zu trennen.

Then the page should be audited for accessibility within "main"; excluding "aside"
Then the page should be axe clean within "main" but excluding "aside"
according to- Accessibility Standard (Tag)-Klausel

Die Tag-Klausel gibt an, welcher Barrierefreiheitsstandard (oder welche Barrierefreiheitsstandards) zur Überprüfung der Seite verwendet werden soll. Die Barrierefreiheitsstandards werden durch Namen (Tag) angegeben. Mehrere Standards können durch Kommas getrennt angegeben werden, zum Beispiel according to: wcag2a, section508. Die zulässigen Tag-Namen sind dokumentiert sowie eine vollständige Auflistung der Regeln, die jedem Tag entsprechen.

Then the page should be audited for accessibility according to: tag-name

Falls gewünscht, kann ein Semikolon (;) verwendet werden, um die Tag-Klausel von der vorhergehenden Klausel zu trennen.

Then the page should be axe clean within "#header"; according to: best-practice
checking- Klausel zur Überprüfung der Regeln

Die Klausel „Checking-Rules“ gibt an, welche zusätzlichen Regeln ausgeführt werden sollen (zusätzlich zu den angegebenen Tags, falls vorhanden, oder dem Standardregelsatz). Die Regeln werden durch Komma-getrennte Regel-IDs angegeben.

Then the page should be axe clean checking: ruleId

Eine Liste gültiger Regel-IDs finden Sie in der Dokumentation der Regeln.

Falls gewünscht, kann ein Semikolon (;) oder das Wort and verwendet werden, um die Prüfregel-Klausel von der vorhergehenden Klausel zu trennen.

Then the page should be axe clean according to: wcag2a; checking: color-contrast
Then the page should be audited for accessibility according to: wcag2a and checking: color-contrast
checking only- Ausschließlichkeitsklausel

Diese Klausel ist nicht wirklich eine separate Klausel. Vielmehr kann die Bedeutung des Schritts durch das Hinzufügen des Wortes only zur Klausel der Prüfregeln geändert werden. Wie oben beschrieben, gibt die Klausel „checking-rules“ standardmäßig zusätzliche Regeln an, die ausgeführt werden sollen. Wird das Wort only verwendet, so werden nur die angegebenen Regeln geprüft.

Then the page should be axe clean checking only: ruleId
skipping- Regelübersprungsklausel

Die Klausel zum Überspringen von Regeln gibt an, welche Regeln übersprungen werden sollen. Dadurch kann ein Zugänglichkeitsstandard bereitgestellt werden (über die Tag-Klausel), während eine bestimmte Regel ignoriert wird. Die Regeln werden durch Komma-getrennte Regel-IDs angegeben.

Then the page should be audited for accessibility skipping: ruleId

Eine Liste gültiger Regel-IDs finden Sie in der Dokumentation der Regeln.

Sie können ein Semikolon (;) oder das Wort but verwenden, um die Skipping-Rules-Klausel von der vorhergehenden Klausel zu trennen, wie unten gezeigt:

Then the page should be axe clean according to: wcag2a; skipping: accesskeys
Then the page should be audited for accessibility according to: wcag2a but skipping: accesskeys
Klauseln, die nur für den Schritt „Auf Barrierefreiheit prüfen“ verfügbar sind

Der be audited for accessibility Matcher bietet Unterstützung für zwei zusätzliche Klauseln.

according to ruleset- Regelsatzklausel

Mithilfe der Regelsatzklausel [according to ruleset] kann ein einzelner Regelsatz (z. B. 508, wcag2, wcag21) angegeben werden, der zum Überprüfen der Seite verwendet werden soll.

Then the page should be axe clean according to ruleset: wcag2
logging results- Klausel zur Protokollierung von Ergebnissen

Um Ergebnisse aus dem Basismatcher und den Klauseln zu protokollieren, rufen Sie die verkettbare Methode logging results wie unten gezeigt auf. Mit der logging results for: report_name Klausel kann der Name des Berichts angegeben werden, der am Ende der Schrittausführung generiert wird.

Then the page should be audited for accessibility logging results for: axe_report_of_my_site
Interoperabilität zwischen Klauseln

Alle beschriebenen Klauseln können mit Methodenverkettung kombiniert und abgestimmt werden. Nachfolgend finden Sie einige Beispiele.

Then the page should be audited for accessibility within "main, header" but excluding "footer"

Then the page should be axe clean excluding "#sidebar" according to: wcag2a, wcag2aa but skipping: color-contrast

Then the page should be audited for accessibility checking only: document-title, label

Then the page should be axe clean according to: best-practice and checking: aria-roles, definition-list

Erweiterte API-Nutzung

Unter Erweiterte Nutzung erfahren Sie, wie Sie die API für Folgendes konfigurieren:

  • Benutzerdefinierte Regeln
  • Benutzerdefinierter Pfad zur axe-Quelle
  • Nutzungsaufzeichnung
  • Berichterstattung