Web52 Konfiguration des "Prüfung der Barrierefreiheit"-Knotens

Die verschiedenen, von QF-Test angebotenen Barrierefreiheitstests, lassen sich über den Prüfung der Barrierefreiheit-Knoten einstellen. Ähnlich wie beim CustomWebResolver installieren-Knoten wird dieser per YAML konfiguriert.
Hierbei können die zu überprüfenden Regeln, Elemente, aber auch weitere Parameter, wie zu ignorierende Fehlermeldungen, eingestellt werden. Zudem bietet der Knoten noch viele Optionen zur Konfiguration der Protokollierung, die außerhalb der YAML-Syntax gesetzt werden können.
Dieses Kapitel beschäftigt sich mit der YAML-Konfiguration des Knotens. Die Optionen für die Protokollierung sind in der Übersicht über den Prüfung der Barrierefreiheit-Knoten genauer beschrieben.

10.0+ Vor QF-Test Version 10.0 erfolgte diese Zuordnung über Prozeduren aus der Standardbibliothek qfs.qft. Diese sind aus Kompatibilitätsgründen weiterhin vorhanden. Die Parameter der Prozedur sind entweder in die YAML-Konfiguration oder in die Felder des Knotens überführt worden.
Mittels der "Knoten konvertieren"-Funktion kann der alte Prozeduraufruf in den neuen Prüfung der Barrierefreiheit-Knoten überführt werden (Rechtsklick auf den Prozeduraufruf → "Knoten konvertieren in" → "Prüfung der Barrierefreiheit").

52.1 YAML-Syntax des Prüfung der Barrierefreiheit-Knotens

Es sind nur Grundkenntnisse der YAML-Syntax nötig, um den Prüfung der Barrierefreiheit-Knoten zu konfigurieren.
Ein kurzer Überblick dazu findet sich im Kapitel CustomWebResolver installieren-Knoten – Syntax.

Die Kategorien Oberkategorie Rules to Check und Oberkategorie Issues to Ignore stehen auf oberster Ebene. Ein Überblick über diese Kategorien und Unterkategorien folgt in späteren Abschnitten.

Das Auswahlmenü, das Sie über den Editier-Button Vorlagen einfügen neben der Zeilennummerierung öffnen, passt sich dem jeweiligen Kontext an und zeigt alle passenden Aktionen für die aktuell ausgewählte Zeile an.

Beispiel des 'Prüfung der Barrierefreiheit'-Knotens mit Auswahlmenü
Abbildung 52.1:  Beispiel des Prüfung der Barrierefreiheit mit Auswahlmenü und Definition

Arbeiten Sie über dieses Menü, behalten Sie stets den vollen Überblick über mögliche Aktionen, während die korrekte Syntax automatisch bereitgestellt wird.

Im folgenden werden alle Konfigurationskategorien sowie deren Unterkategorien, die in der YAML-Syntax verwendet werden können, kurz erklärt.

52.2 Oberkategorie Rules to Check

In der Kategorie Rules to Check werden die Barrierefreiheitstests definiert, die QF-Test ausführen soll. Aktuell stehen folgende Checks zur Verfügung:

axe

Rules to Check – axe: Barrierfreiheitstests basierend auf der axe-core Library (siehe Axe-Checks mit QF-Test)

color-contrast-simple-graphics

Rules to Check – color-contrast-simple-graphics: Farbkontrastüberprüfung einfacher Nicht-Textelemente wie etwa Icons, Buttons ... (siehe Farbkontrast-Check für einfache Grafikobjekte)

focus-visible

Rules to Check – focus-visible: Überprüfung der Sichtbarkeit des Fokus, wenn dieser durch den Benutzer auf Elemente gesetzt wird (siehe Überprüfung der Sichtbarkeit des Fokus)

language-lang-value

Rules to Check – language-lang-value: Überprüfung den Wert des lang-Attributes im HTML Dokument (siehe Überprüfung des Sprachattributes)

Rules to Check:
  axe:
    Rules:
    - button-name
    - input-button-name
    - aria-command-name
    Scope: "genericDocument"
    Logging ID: Button Title Tests
  color-contrast-simple-graphics:
    Generic Classes:
    - Icon
    Generic Classes to Skip:
    - Icon:Decorative
  focus-visible: true
  language-lang-value:
    Scope: "#iframe:Videoplayer"
    Expected Lang Value: de
Beispiel 52.1:   Definition mehrerer Barrierefreiheitsüberprüfungen

52.2.1 Generische Parameter der Barrierefreiheitstests

Jeder Barrierefreiheitstest lässt sich mit folgenden Parametern konfigurieren:

Scope

Hier wird die QF-Test ID der Komponente angegeben, innerhalb derer die Checks angewandt werden sollen. Die Tests werden nur auf diese Komponente und ihre Kindkomponenten angewendet.

Sollten in der (Smart)ID der angegebenen Komponente YAML-spezifische Sonderzeichen, wie etwa "#", vorkommen, muss der Wert in Anführungszeichen gesetzt werden, damit die Komponente korrekt erkannt werden kann.

Rules to Check:
  color-contrast-simple-graphics:
    Generic Classes:
    - Icon
    Scope: "#Menubar:name=Navbar"
  focus-visible:
    Scope: "#TabPanel:name=TabbedPane"
Beispiel 52.2:  Einschränkung des zu überprüfenden Bereichs auf Komponenten, adressiert über SmartIDs

Default: genericDocument, also die gesamte Seite.

Generic Classes to Skip

Eine Liste an Namen von Generische Klassen, die bei den Tests übergangen werden sollen. Diese Klassen und eventuelle Unterklassen werden bei den Tests nicht überprüft.

Rules to Check:
  axe:
    Rules:
    - nested-interactive
    - color-contrast
    Generic Classes to Skip:
    - Button
    - CustomClass
Beispiel 52.3:   Ausschließen mehrerer Klassen von der Überprüfung

Default: leer - es werden keine Klassen bei der Überprüfung ausgeschlossen

Check Rule

Ein Boolean-Parameter, der steuert, ob die Regel ausgeführt werden soll. Insbesondere nützlich um beim Debuggen der Tests einzelne Tests schnell auszuschalten.

Zudem lassen sich die Barrierefreiheitstests schnell mit Standardwerten ausführen, indem hinter die alleinstehende Regel true geschrieben wird - eine QF-Test spezifische Abkürzung für Check Rule: true.

Rules to Check:
  axe:
    Check Rule: false
    Rules:
      - wcag2a
      - wcag2aa
  focus-visible: true
Beispiel 52.4:   Deaktivierung der axe-Tests und Abkürzung durch den Check Rule-Parameter zur Ausführung des focus-visible-Tests

Default: true

52.2.2 Rules to Checkaxe

Für Axe-Checks mit QF-Test lassen sich die zu überprüfenden Regeln oder Regelgruppen wie folgt einstellen:

Rules

Rule-IDs der Axe-Regeln oder die von Axe definierten Tags (dequeuniversity.com/rules/axe/html).

Jede Regel hat einen Namen (rule-id), über den sie angesprochen werden kann.

Ist eine Regel erforderlich für die Erfüllung bestimmter Barrierefreiheitsstandards, wird dieser Standard in den Tags der Regel aufgelistet. Eine Regel, die etwa für die Erfüllung einer WCAG-Richtlinie 2.1 des Levels AA Voraussetzung ist, wird unter anderem den Tag "wcag21aa" besitzen.
Die so definierten Regelgruppen können über ihre Tags aufgerufen werden.

HinweisWichtig: Die auszuführenden axe-Regeln werden in einem Aufruf entweder direkt per Regel-ID oder per Gruppenzugehörigkeit (Tags) angesprochen. Es können mehrere Regel-IDs oder Tags angegeben werden - aber eine Mischung aus IDs und Tags ist nicht möglich.

Rules to Check:
  axe:
    Rules:
    - wcag2a
    - wcag2aa
    - wcag21a
    - wcag21aa
    - wcag22aa
Beispiel 52.5:  Ausführen aller WCAG-relevanter axe-Regeln über Tags

Wird der Parameter leer gelassen oder explizit auf all gesetzt, werden sämtliche von axe-core bereitgestellten Regeln überprüft.

Default: alle Tags der für die Erfüllung der WCAG relevanten axe-Regeln

Rules to Skip

Ist der Rules-Parameter leer oder mit Tags befüllt, so ist es hier möglich einzelne Regeln von der Überprüfung auszuschließen. Hierfür muss eine Liste an IDs von Axe-Regeln angegeben werden.

Rules to Check:
  axe:
    Rules:
    - wcag2a
    - wcag2aa
    Rules to Skip:
    - button-name
    - aria-required-attr
Beispiel 52.6:   Ausschließen einzelner Regeln per Rules to Skip

Default: leer

Logging ID

Hier lässt sich ein Name vergeben, unter diesem die mit in diesem axe-Check definierten Regeln im Protokoll gelistet werden.

Rules to Check:
  axe:
    Rules:
    - button-name
    - input-button-name
    - aria-command-name
    Logging ID: Button Title Tests
Beispiel 52.7:   Zusammenfassen mehrerer axe-Regeln zu einem Namen für das Protokoll

Default: leer

52.2.3 Rules to Checkcolor-contrast-simple-graphics

Für Farbkontrast-Check für einfache Grafikobjekte lassen sich die zu überprüfenden Elemente wie folgt einstellen:

Generic Classes

Der Name einer oder mehrerer generischer Klassen (siehe Generische Klassen). Alle Elemente dieser Klasse innerhalb des Scope werden auf ihren Farbkontrast überprüft.

Rules to Check:
  color-contrast-simple-graphics:
    Generic Classes:
    - Icon
    - <SVG>
    Generic Classes to Skip:
    - Icon:Decorative
Beispiel 52.8:  Festlegen der zu überprüfenden generischen Klassen

Default: Graphics

52.2.4 Rules to Checkfocus-visible

Für Überprüfung der Sichtbarkeit des Fokus kann die Länge des Tests über den folgenden Parameter beschränkt werden:

Allowed Number of Elements without Tabindex

Interaktive HTML-Elemente wie <button>, <input> oder <a> sind standardmäßig fokussierbar. Aber durch Verwendung des tabindex-Attributes können auch andere Elemente im HTML fokussierbar gemacht werden.

Damit alle Elemente mit einem explizit gesetztem tabindex überprüft werden können, ist die Anzahl dieser Elemente das untere Limit der durch den Test simulierten Tabulator-Tastendrücke.
Mit Allowed Number of Elements without Tabindex kann somit ein oberes Limit an Tastendrücken festgelegt werden.

Rules to Check:
  focus-visible:
    Allowed Number of Elements without Tabindex: 500
Beispiel 52.9:   Erhöhen der Anzahl der maximalen Tabulator-Tastendrücke

Default: 300

52.2.5 Rules to Checklanguage-lang-value

Für die Überprüfung des Sprachattributes muss der erwartete Wert des HTML-lang Attributes definiert werden.

Expected Lang Value

Der Wert der Sprache, die im HTML-lang Attribut erwartet wird (W3Schools). Werte sind beispielsweise "en" für Englisch, "de" für Deutsch oder "fr" für Französisch. Durch einen Anhang kann eine Regionalsprache eingestellt werden, etwa "en-GB" für britisches Englisch, oder "fr-CA" für kanadisches Französisch.

Rules to Check:
  language-lang-value:
    Expected Lang Value: de
Beispiel 52.10:   Festlegen der erwarteten Sprache

Default: en

52.3 Oberkategorie Issues to Ignore

In der Kategorie Issues to Ignore können Fehler angegeben werden, die QF-Test bei der Erstellung von Protokollen und Reports ignorieren soll. Diese Funktion ist beispielsweise hilfreich, um bekannte Probleme, die eine sehr niedrige Priorität bei der Fehlerbehebung haben, aus der Protokollierung auszuschließen. Dabei wird insgesamt keine Information verloren, da die Fehler in diesem Parameter gelistet bleiben - nur Protokoll und Report werden übersichtlicher.

Mit Issues to Ignore werden spezifische Fehler und Warnungen ignoriert. Es ist also sinnvoll, diese Konfiguration anhand von vorhandenen Fehlermeldungen zu erstellen, da Informationen aus der Fehlermeldung benötigt werden.

Issues to Ignore:
- URL: https://
  Errors:
  - Rule ID: color-contrast
    Message: "Das Element hat einen unzureichenden Kontrast von [0-2]"
    Elements:
    - XPath: "/html/body/div[2]/div[4]/div/p[5]/a[2]"
    - XPath: "/html/body/div[2]/div[4]/div/p[7]/a"
  - Rule ID: focus-visible
    Message: "Das tabbare Element ändert sich nicht unter dem Fokus"
    Elements:
    - XPath: "/html/body/div[2]/div[3]/div/div/div/div/div/figure/div/div[2]/a"
  Warnings:
  - Rule ID: video-caption
    Message: "Für das Element konnte keine Untertitelung"
    Elements:
    - XPath: "/html/body/header/div[3]/video"
- URL: https://www.example.com/components/lists.html
  Errors:
  - Rule ID: listitem
    Message: "Aufzählungselement besitzt kein gültiges Elternelement (<ul>, <ol>)"
    Elements:
    - XPath: "/html/body/div[2]/div[18]/div/div/div/div/ul/div/div/li[4]"
    - XPath: "/html/body/div[2]/div[18]/div/div/div/div/ul/div/div/li[5]"
    - XPath: "/html/body/div[2]/div[18]/div/div/div/div/ul/div/div/li[6]"
    - XPath: "/html/body/div[2]/div[18]/div/div/div/div/ul/div/div/li[7]"
Beispiel 52.11:   Festlegen mehrerer Fehler und Warnungen zum Ausschluss aus dem Protokoll

Rule ID, Message und XPath müssen bei einem Fehler bzw. einer Warnung auf der durch die URL gekennzeichnete Seite übereinstimmen, damit diese aus dem Protokoll ausgeschlossen werden.
Standardwerte sind im "Issues to Ignore"-Parameter nicht vorhanden.

52.3.1 Issues to Ignore - URL

Die zu ignorierenden Fehler werden für jede zu überprüfende Seite separat definiert. Im ersten Schritt muss also die URL der Seite angegeben werden, auf der der Fehler auftritt.

Die hier angegebene URL muss nicht die vollständige URL der zu überprüfenden Seite sein, sondern kann einen Teil der Adresse darstellen. Alternativ kann ein passender regulärer Ausdruck angegeben werden (siehe Reguläre Ausdrücke - Regexps). Die Einstellungen für die zugehörigen Warnungen und Fehler (Issues to Ignore - Errors und Warnings) beziehen sich auf die hier angegebene URL.

Wird beispielsweise "https://www.qftest.com" als URL angegeben, so gelten die darauf folgenden Einstellungen der zu ignorierenden Regeln für alle Seiten, deren URL "https://www.qftest.com" beinhaltet.
Es können beispielsweise auch alle Seiten, die HTTPS verwenden definiert werden, indem der Wert "https://" als Wert für die URL eingetragen wird.

52.3.2 Issues to Ignore - Errors und Warnings

Als nächstes wird bestimmt, welche Fehler oder Warnungen im Protokoll ignoriert werden sollen. Die folgenden Einstellungsmöglichkeiten sind Listeneinträge unter "Errors"/"Warnings" und in beiden Fällen gleich:

Rule ID

Die ID der Regel (Oberkategorie Rules to Check), welche im Protokoll ignoriert werden soll. Diese findet sich beispielsweise am Anfang einer Fehlermeldung. Im Falle eines Tests mit der axe-core Library (Axe-Checks mit QF-Test) entspricht sie der "rule-id", die in dequeuniversity.com/rules/axe/html/ gelistet ist.

Ansonsten entspricht sie dem Wert, der auch unter dem Rules to Check-Parameter angegeben wurde, etwa "focus-visible" oder "color-contrast-simple-graphics".

Message

Die zu ignorierende Fehlermeldung.
Hier kann der Text der gesamten Fehlermeldung (in der Nachricht im Protokoll/Report zu finden unterhalb der Elemente) übergeben werden, es reicht aber auch ein Ausschnitt aus der Fehlermeldung.
Der angegebene Wert wird als regulärer Ausdruck interpretiert (siehe Reguläre Ausdrücke - Regexps).

Sollten in der Message YAML-spezifische Sonderzeichen, wie etwa ":" oder "#", vorkommen, sollte der Wert in Anführungszeichen gesetzt werden - hierfür genügt ein Klick auf den "Reformatieren" Knopf oberhalb der YAML-Definition.

Elements

Eine Liste an der fehlerhaften Elemente, die in der Fehlermeldung gelistet werden. Die Elemente werden über den XPath bestimmt.

Elements:
- XPath: /html/body/main/article/section/h2
- XPath: "/html/body/main/article/section/ul/li[2]/div/a/h3"
- XPath: /html/body/main/article/section/ul/li/div/p
Beispiel 52.12:   Festlegen der zu ignorierenden Elemente