Anpassung der Axe DevTools für Web-Accessibility-Regeln
Ändern Ihrer Regelkonfiguration in Axe DevTools für das Web
Innerhalb der Axe DevTools-APIs besteht die Möglichkeit, Ihr Standardregelset sowie Ihre axe-core-Version zu ändern. Wenn Axe DevTools aktualisiert wird, ändern sich das Regelset und die axe-core-Version. Für Benutzer, die nur ein Werkzeug nutzen, spielt die spezifische Regelset-Konfiguration und axe-core-Version möglicherweise keine Rolle. Für Benutzer mehrerer Axe DevTools-Komponenten sorgt das gleiche Regelkonfiguration und die gleiche axe-core-Version dafür, dass die Scan-Ergebnisse zwischen den Tools zu 100 % konsistent sind.
Regelset-Konfiguration
Axe DevTools hat die Fähigkeit, eine Vielzahl von Regelkonfigurationen zu verwenden. Für weitere Informationen zu den verschiedenen Regelsets lesen Sie die Seite über axe-core Regelsets. Sie können zu einem der anderen WCAG-Regelsets, ADA Section 508, Trusted Tester v5, EN 301 549 oder RGAA wechseln. Zusätzlich können Modifikationen dieser Regelsets wie Best Practices, die nicht unter WCAG oder Section 508 fallen, oder völlig neue experimentelle Regeln zu jeder Regelset-Konfiguration hinzugefügt werden. Für eine Beschreibung jedes Regelsets siehe Regelsets.
Das Standardregelset
Wenn Sie nichts anderes konfigurieren, testen die Axe DevTools für Web-APIs und die CLI gegen WCAG 2.1 Level AA, identifiziert durch die Regelset-ID wcag2.1. Da die WCAG-Regelsets kumulativ sind, deckt dies die Level A und Level AA Regeln von sowohl WCAG 2.0 als auch WCAG 2.1 ab.
Unter dem Standardregelset werden Regeln, die mit best-practice oder experimental gekennzeichnet sind, aus geschaltet. Ein Standardscan meldet nur Fehler, die den Erfolgskriterien der WCAG 2.1 Level A und AA entsprechen, sodass er die Best-Practice-Ergebnisse von Deque nicht anzeigt, es sei denn, Sie fordern sie an.
Best-Practice-Regeln sind nicht Teil eines Zugänglichkeitsstandards, aber sie tragen dazu bei, eine Website so fair wie möglich nutzbar zu machen. Wie Sie sie aktivieren, hängt von der Sprache ab, und nicht jede Integration bietet einen dedizierten Schalter:
| Sprache | Aktivierung von Best Practices |
|---|---|
| Java | Übergeben Sie true als zweites Argument an forRuleset(rulesetId, enableBestPractices). Siehe die Java Selenium API-Referenz. |
| C# | Übergeben Sie true als zweites Argument an WithRuleset(rulesetId, enableBestPractices). Siehe die C# API-Referenz. |
| Python | Übergeben Sie enable_best_practices=True an with_ruleset(). Siehe die Python API-Referenz. |
| Node.js und JavaScript | Playwright, Puppeteer und WebdriverIO akzeptieren eine enableBestPractices-Option. Andere Integrationen wählen Regeln stattdessen nach Tag aus. Siehe die Node.js und JavaScript Übersicht. |
| Ruby | Es gibt kein Best-Practices-Flag. Fügen Sie das best-practice-Tag durch die Tag-Klausel hinzu, die für RSpec und Cucumber beschrieben ist. |
| CLI | Erstellen Sie eine Regelset-Datei, die die Best-Practice-Regeln enthält, und wenden Sie sie mit --custom an. Siehe Benutzerdefinierte Regelsets. |
Um stattdessen gegen einen anderen Standard zu testen, übergeben Sie dessen Regelset-ID an derselben Stelle. Verwendung des RGAA-Regelsets beschreibt das für einen Standard und listet die Auswahlmethode für jede Sprache auf.
axe-core Version
Die Barrierefreiheitstest-Engine hinter Axe DevTools, axe-core, wird kontinuierlich aktualisiert und verbessert. Aus diesem Grund können unterschiedliche Versionen von axe-core möglicherweise nicht immer die gleichen Scan-Ergebnisse liefern. Die Gewährleistung, dass Ihre axe-core-Version zwischen Komponenten, Entwicklern und Entwicklungsteams konsistent ist, eliminiert die Risiken, die mit unterschiedlichen Scans verbunden sind, die unterschiedliche Ergebnisse liefern. In Axe DevTools wird Ihre axe-core-Version mit Ihrer Axe DevTools-Version synchronisiert. Es besteht die Möglichkeit, spezifische axe-core-Versionen zu importieren.