Hamcrest-Tests schreiben

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

Barrierefreiheitstests mit Hamcrest Matchers und Axe DevTools für Web für Java schreiben

Not for use with personal data

Voraussetzungen

Um Barrierefreiheitstests zu schreiben und Ergebnisse zu erzielen, müssen Sie bereits eine Testdatei mit Axe DevTools erstellt und Ihre Wahl des Selenium WebDriver vorimportiert und vorinitialisiert haben. Falls Sie dies noch nicht getan haben, lesen Sie diese Anleitung, wie das geht.

Ein Satz von Matchern wurde für Barrierefreiheitstests über Hamcrest unter Verwendung von Selenium WebDriver bereitgestellt. Diese Matcher können in einem Unit-Test-Framework oder in benutzerdefinierten Cucumber-Schritten verwendet werden.

Auswahl einer Scanning-Methode

Wie in den Importanweisungen zu sehen ist, gibt es zwei Methoden zur Barrierefreiheitsprüfung. Die erste, isAxeClean, wirft eine Ausnahme und stoppt die Tests, wenn Verstöße gefunden werden. Die zweite, isAuditedForAccessibility, stoppt die Tests nicht und wirft keine Ausnahme, unabhängig vom Barrierefreiheitsgrad der gescannten Seite.

Tests schreiben

Für die restlichen Beispiele wird die Methode isAxeClean der Einfachheit halber gezeigt, aber beide Methoden funktionieren austauschbar. Mit Ihren instanziierten und initialisierten WebDriver- und AxeDriver-Objekten ist das Erstellen eines Scans so einfach wie das Hinzufügen dieser zwei Codezeilen zu einer Testmethode. Ersetzen Sie $URL durch die gewünschte URL der Seite, die Sie scannen möchten.

webDriver.get("$URL");
assertThat(axedriver, isAxeClean());

Beim Testen mehrerer Seiten können Sie den Abruf- und Scanprozess wiederholen, ohne neue Instanzen der Treiber erstellen zu müssen. Um verschiedene Zustände einer Seite zu scannen, können Sie die Seite mit der WebDriver-API manipulieren und dann einen neuen Scan durchführen.

Zusätzliche Referenz

Es stehen mehrere Verkettungsmethoden zur Verfügung, um die Art und Weise, wie die Seite gescannt wird, zu modifizieren. Diese Methoden umfassen Ausschluss-/Einschlussklauseln oder die Festlegung und Modifizierung von Barrierefreiheitsstandards, Barrierefreiheitsregeln und Barrierefreiheitsregelsets. Der Kürze halber sind alle Kettenmethoden mit isAxeClean() gekoppelt, sie sind jedoch austauschbar mit isAuditedForAccessibility().

Barrierefreiheitsstandards

Deque bietet eine Kettenmethode, gemäß, die direkt angibt, welche Barrierefreiheitsteststandards von einem Scan verwendet werden.

Tag-Name Barrierefreiheitsstandard
wcag2a WCAG 2.0 Level A
wcag2aa WCAG 2.0 Level AA
wcag2aaa WCAG 2.0 Level AAA
wcag21a WCAG 2.1 Level A
wcag21aa WCAG 2.1 Level AA
wcag21aaa WCAG 2.1 Stufe AAA
wcag22a WCAG 2.2 Level A
wcag22aa WCAG 2.2 Level AA
wcag22aaa WCAG 2.2 Level AAA
section508 Section 508
EN-301-549 EN 301 549
RGAAv4 RGAA Version 4
TTv5 Trusted Tester v5
best-practice Von Deque empfohlene Best Practices

Wenn Sie sich nicht sicher sind, welcher Standard für Sie der richtige ist, lesen Sie die axe-core-Dokumentation darüber, welche Regeln mit welchem Standard verbunden sind, oder kontaktieren Sie uns über Ihren Deque-Ansprechpartner oder unser Helpdesk. Für eine vollständige Liste, welche Regeln für jeden Standard gelten, sehen Sie sich diese Seite zu Regelbeschreibungen an

Um einen einzelnen Standard zu verwenden, fügen Sie einfach die gemäß-Kettenmethode hinzu und übergeben Sie Ihren gewünschten Standard

assertThat(axedriver, isAxeClean().accordingTo("wcag2a"));

Um gegen zwei oder mehr Teststandards zu prüfen, übergeben Sie alle in einem Aufruf. Ein zweiter Aufruf von accordingTo ersetzt die Standards aus dem ersten Aufruf, anstatt sie hinzuzufügen.

assertThat(axedriver, isAxeClean().accordingTo("wcag2a", "section508"));

Eingrenzung

Deque bietet zwei verkettete Methoden, um bei der Festlegung von Scanbereichen zu helfen. Die within()-Methode ändert den Scan so, dass nur der Bereich innerhalb der Grenzen des an sie übergebenen Selektors gescannt wird. Die excluding()-Methode funktioniert umgekehrt. Sie ändert den Scan so, dass der Inhalt innerhalb des an sie übergebenen Selektors ignoriert wird. Die untenstehenden Beispiele zeigen alle die within()-Methode, aber die excluding()-Methode funktioniert identisch.

Am einfachsten wird die Assertion mit einem Selektor modifiziert

assertThat(axedriver, isAxeClean().within("#selector1")); 

Es sind auch zusammengesetzte Selektoren möglich. Im unten stehenden Beispiel werden nur Elemente mit Selektor 2 innerhalb von Selektor 1 gescannt

assertThat(axedriver, isAxeClean().within("#selector1 .selector2"));

Es gibt drei Möglichkeiten, eine Mehrfachauswahl durchzuführen oder mehrere Gültigkeitsbereiche für Tests auszuwählen. In all diesen Beispielen befinden sich Elemente innerhalb von Selektor 1 und Selektor 2.

assertThat(axedriver, isAxeClean().within("#selector1, .selector2"));
assertThat(axedriver, isAxeClean().within("#selector1", ".selector2"));
assertThat(axedriver, isAxeClean().within("#selector1").within(".selector2"));

Um innerhalb eines IFrames einzuschränken, muss ein IFrame-Selektor deklariert werden. Der abzugrenzende Bereich innerhalb des IFrames wird als zusätzliches Argument übergeben.

assertThat(axedriver, isAxeClean().within(new IFrameSelector("#frame1", "#selector1")));

Die Einschränkung innerhalb mehrerer IFrames funktioniert genauso wie die standardmäßige Mehrfachauswahl. Man muss einfach zwei oder mehr IFrame-Selektoren durch Kommas getrennt erstellen.

assertThat(axedriver, isAxeClean().within(new IFrameSelector("#frame1", "selector1"), 
        new IFrameSelector("#frame2", "#selector2")));

Es ist auch möglich, innerhalb verschachtelter IFrames einzuschränken. Dieses Beispiel zeigt, wie ein Scan innerhalb von Selektor 1 eines IFrames durchgeführt wird, das sich in einem zweiten IFrame befindet.

assertThat(axedriver, isAxeClean().within(
    new IFrameSelector("#frame1",
    new IFrameSelector("#frame2", "#selector1"))));

Schließlich ist es möglich, mehrere Bereiche sowohl auf einer Seite als auch innerhalb eines IFrames festzulegen. Damit dies funktioniert, wird ein Elementselektor-Objekt benötigt.

assertThat(axedriver, isAxeClean().within(
    new ElementSelector("#selector1"),
    new ElementSelector("#selector2"),
    new IFrameSelector("#frame", "selector3")));

Regelauswahl

Die API bietet auch die Möglichkeit, zu modifizieren, welche Regeln bei einem Scan verwendet werden. Es gibt drei Möglichkeiten, dies zu tun. Diese sind: zusätzliche Regeln außerhalb des Standardregelsets für den Scan zu überprüfen, Regeln innerhalb des Standardregelsets für den Scan nicht zu überprüfen und nur die explizit angegebenen Regeln zu überprüfen.

Für eine vollständige Liste der gültigen Regel-Tags, die Sie mit diesen Methoden verwenden können, und was sie testen, lesen Sie die Dokumentation zu Regeln

Um zusätzliche Regeln zu überprüfen, verwenden Sie die checking-Methode. Um eine einzelne zusätzliche Regel zu testen, geben Sie einfach das Regel-Label in die checking-Methode ein

assertThat(axedriver, isAxeClean().checking("label"));

Um mehrere zusätzliche Regeln zu überprüfen, übergeben Sie alle in einem Aufruf. Ein zweiter Aufruf von checking ersetzt die Regeln aus dem ersten Aufruf, anstatt sie hinzuzufügen.

assertThat(axedriver, isAxeClean().checking("label", "tabindex"));

Die checking-Methode kann auch mit einer Regelauswahlmethode verkettet werden.

assertThat(axedriver, isAxeClean().accordingTo("wcag2a").checking("tabindex"));

Es besteht auch die Möglichkeit, Regeln von einem Scan auszuschließen. Dies ist über die skipping-Methode möglich. Sie funktioniert identisch zur checking-Methode, außer dass sie Regeln ausschließt, anstatt sie hinzuzufügen.

assertThat(axedriver, isAxeClean().skipping("label"));

Um mehrere Regeln auszuschließen, übergeben Sie alle in einem Aufruf. Wie bei checking ersetzt ein zweiter skipping-Aufruf die Regeln aus dem ersten.

assertThat(axedriver, isAxeClean().skipping("label", "tabindex"));

Schließlich kann sie auch mit einer Regelauswahlmethode verwendet werden.

assertThat(axedriver, isAxeClean().accordingTo("wcag2a").skipping("label"));

checking und skipping setzen dieselbe Option, daher wird nur der letzte der beiden Aufrufe in einer Kette wirksam. Kombinieren Sie sie nicht in derselben Prüfung.

Die letzte Methode wird verwendet, wenn nur bestimmte Regeln gewünscht sind. Die nur überprüfende Methode modifiziert die Prüfung so, dass nur die explizit übergebenen Regeln überprüft werden. checkingOnly und accordingTo setzen dieselbe Option, daher wird nur die letzte der beiden wirksam. Um nur eine einzelne Regel zu überprüfen:

assertThat(axedriver, isAxeClean().checkingOnly("label"));

Um mehrere Regeln zu überprüfen, übergeben Sie alle in einem Aufruf. Ein zweiter checkingOnly-Aufruf ersetzt die Regeln aus dem ersten.

assertThat(axedriver, isAxeClean().checkingOnly("label", "tabindex"));

Für eine vollständige Liste der gültigen Regel-Tags, die Sie mit diesen Methoden verwenden können und was sie testen, lesen Sie den Dokumentation zu Regeln.

Verletzungen ignorieren

Es ist möglich, die Prüfung so zu konfigurieren, dass spezifische Instanzen von Verstößen ignoriert werden. Um dies zu tun, wird die Ignoriermethode verwendet. Sie funktioniert, indem der target des Elements, das ignoriert werden soll, so wie es in den Ergebnissen erscheint, zusammen mit der Regel, die es verletzt, übergeben wird. Das Ziel wird so geschrieben, wie Java eine Liste ausgibt, mit dem Selektor in eckigen Klammern, wie "[.sidebar]". Ein ignoring-Aufruf pro Regel reicht aus, da ein Treffer den gesamten Eintrag der Regel entfernt. Rufen Sie es nicht zweimal für dieselbe Regel auf: Wenn beide Ziele zu den fehlgeschlagenen Elementen passen, löst die Prüfung einen IllegalStateException aus.

assertThat(axedriver, isAxeClean()
    .ignoring("[.sidebar]", "color-contrast")
    .ignoring("[#branded-content]", "image-alt"));

Wenn das Ziel einem Element entspricht, das die Regel verletzt, wird der gesamte Eintrag der Regel aus den Verstößen entfernt, einschließlich der Fehler bei anderen Elementen. Siehe ignoring(String, String) in der API-Referenz.

Nutzungsdienst

Erhalten Sie Einblicke in die Nutzungstrends von Axe DevTools innerhalb Ihrer Organisation

Standardmäßig ist der Nutzungsdienst aktiviert und die Standard-URL ist https://usage.deque.com. Setzen Sie die Umgebungsvariable AXE_TRACK_USAGE auf false, um ihn zu deaktivieren. Wenn Ihre Nutzungsevents Deque nicht erreichen, setzen Sie die Umgebungsvariable AXE_METRICS_URL explizit.

Umgebungsvariablen

Diese Umgebungsvariablen ermöglichen es Ihnen, den Nutzungsservice zu konfigurieren und die Eigenschaften der gemeldeten Ereignisse zu ändern.

Name Typ Kann überschrieben werden Beschreibung
AXE_DISTINCT_ID String — Ein UUID-Identifikator, der für den angemeldeten Benutzer gleich bleibt (außer er wird neu generiert). In Ruby heißt diese Variable DEQUE_DISTINCT_ID.
AXE_INCLUDE_TEST_RESULTS Boolean — Setzen Sie true, um die vollständigen axe-core-Ergebnisse im testResults-Objekt jedes Ereignisses einzuschließen (Standard ist false). Wird nur von der CLI und den Node.js-APIs unterstützt.
AXE_METRICS_URL String — Die URL des REST-Nutzungsendpunkts (Standard ist https://usage.deque.com)
AXE_TRACK_USAGE Boolean — Setzen Sie false, um das Reporting des Nutzungsdienstes zu deaktivieren. Das Reporting ist standardmäßig aktiviert.
AXE_ACTOR String — Auf human oder automation setzen, um zu überschreiben, ob Ereignisse eine Person oder eine automatisierte Pipeline als Ausführende der Tests protokollieren. Standardmäßig wird automation aus den üblichen CI-Umgebungsvariablen ermittelt. Unterstützt von der CLI, den Node.js-APIs und nur der Ruby-API.
AXE_APPLICATION String false Die Anwendung, die verwendet wurde, um Barrierefreiheitsfehler zu überprüfen
AXE_DEV_INSTANCE Boolean true Zeigt an, ob dieses Ereignis durch die Aktionen eines Softwareentwicklers entstanden ist. Nützlich zum Markieren und späteren Entfernen von Ereignissen, die während der Entwicklung oder des Testens protokolliert wurden.
AXE_DEPARTMENT String true Die Abteilung des Benutzers innerhalb der Organisation
AXE_KEYCLOAK_ID String false Die Keycloak-ID des Benutzers
AXE_LOGGED_IN Boolean false Zeichnet auf, ob der Benutzer im zu testenden Anwendung angemeldet ist
AXE_ORGANIZATION String true Die Organisation des Benutzers. Um Ihre Nutzung in Axe Reports anzuzeigen, setzen Sie dies auf die ID Ihrer Organisation (kontaktieren Sie Deque, um diese zu erhalten).
AXE_SESSION_ID String false Ein UUID, das die Sitzung des Benutzers identifiziert
AXE_TEAMS String false Die Teams, die die Tests durchführen, als JSON-Array von { "id": "...", "name": "..." } Objekten oder der Pfad zu einer JSON-Datei, die eines enthält. Ein an die --set-teams-Option der CLI übergebener Wert, eine setTeams-Methode der Node.js-API oder eine for_teams-Klausel bzw. teams-Konfigurationseigenschaft der Ruby-API hat Vorrang. Unterstützt von der CLI, den Node.js-APIs und nur der Ruby-API.
AXE_USER_ID String false Die Identität eines bestimmten Benutzers, wie eine E-Mail-Adresse, ein Name oder eine Login-ID. Axe Reports zählt anhand dieses Wertes eindeutige Benutzer.
AXE_USER_JOB_ROLE String false Die Rolle des Benutzers im Beruf
AXE_USER_STATUS String false Statusinformationen, die Sie mit dem Benutzer verknüpfen möchten

Nächste Schritte

Für die weitere Nutzung Ihrer Axe DevTools-Scannergebnisse, wie z.B. Berichte, sehen Sie die Dokumentation zum Axe DevTools Java Selenium-Paket

Fehlerbehebung

Wenn Sie Probleme bei der Einrichtung Ihres Barrierefreiheitstests haben, kontaktieren Sie direkt Ihren Deque-Ansprechpartner, erreichen Sie uns über unseren Support-Desk oder senden Sie uns eine E-Mail. Wir helfen Ihnen gerne, Ihre Barrierefreiheitstestbemühungen in Gang zu bringen.