Glossar

a11y

Eine Abkürzung für Barrierefreiheit: interpretiert als der Buchstabe a, gefolgt von 11 Zeichen und dann der Buchstabe y.

Agora

Agora ist das interne Artefakt-Repository von Deque. Es basiert auf einer Artifactory-Instanz. Über Agora können Benutzer Komponenten von Axe DevTools herunterladen, benutzerdefinierte Regelsätze verwalten und verteilen und mehr.

API-Schlüssel

Ein API-Schlüssel autorisiert die CLI, Axe Watcher oder die Web-APIs, Barrierefreiheitsergebnisse an Axe Developer Hub oder Axe Reports zu senden. Behandeln Sie Ihren API-Schlüssel als geheime Anmeldeinformation: Kommittieren Sie ihn nicht in die Versionsverwaltung und teilen Sie ihn nicht. Speichern Sie ihn in einer Umgebungsvariable oder im Geheimnismanager Ihrer CI/CD-Plattform.

ARIA

Accessible Rich Internet Applications (ARIA) ist eine technische Spezifikation, die vom World Wide Web Consortium oder W3C veröffentlicht wurde und Möglichkeiten definiert, die Zugänglichkeit von Webseiten zu erhöhen, insbesondere von dynamischen Inhalten und Benutzeroberflächenkomponenten, die mit Ajax, HTML, JavaScript und verwandten Technologien entwickelt wurden.

Assistive Technologie

Einige Menschen mit Behinderungen können nicht eigenständig mit Software und Webseiten interagieren. Diese Personen benötigen unterstützende Technologie, um das Internet auf eine gleichberechtigte Weise zu nutzen. Eine sehr häufige Form der unterstützenden Technologie ist ein Bildschirmleser. Diese Geräte lesen den Text auf dem Bildschirm für Menschen mit Sehbehinderung oder Blinde laut vor. Es gibt viele verschiedene Bildschirmleser, je nach Plattform. Einige Beispiele sind NVDA oder JAWS auf dem PC, VoiceOver auf dem Mac oder TalkBack auf Android.

Best Practices

Deque-Best Practices sind bewährte Techniken, die gewünschte Barrierefreiheitsergebnisse liefern, wenn spezifische formale Methoden fehlen oder unzureichend sind. Obwohl sie offiziell in keinem etablierten Barrierefreiheitsregelset enthalten sind, kann die Befolgung von Deques Best Practices die Barrierefreiheit und die Gesamtqualität der getesteten Webseite verbessern. Es sollte beachtet werden, dass die Nichteinhaltung der Deque-Best-Practice-Richtlinien nicht automatisch ein Scheitern bedeutet. Darüber hinaus ist eine fachkundige Beurteilung erforderlich, um die Angemessenheit im Kontext der Ziele der Anwendung, Website oder Seite zu berücksichtigen. Manchmal ist die bestmögliche Barrierefreiheitstechnik nicht anwendbar oder praktisch zur Lösung eines bestimmten Problems. Siehe Best Practices für die Regeln, die das Best-Practice-Regelset bilden.

Browser-Automatisierungsplattform

Für Axe Watcher ist ein Browser-Automatisierungsplattform ein Framework, das Sie verwenden, um Ihre Website-Tests zu automatisieren. Zu den Plattformen gehören Cypress, Playwright, Puppeteer, WebdriverIO und WebDriverJS. Weitere Informationen finden Sie unter

• Cypress
• Playwright oder Playwright Test
• Puppeteer
• WebdriverIO oder WebdriverIO Testrunner
• WebDriverJS

Prüfpunkt

Ein bewährtes Verfahren zum Testen von Barrierefreiheitsanforderungen, das von Deques Team von a11y-Experten erstellt wurde und die Konsistenz und Genauigkeit der Testergebnisse erhöht. Basierend auf den WCAG-Erfolgskriterien bieten sie eine explizitere Kategorisierung und Interpretation dieser Richtlinien, wobei Fehler typischerweise nach Inhaltstyp getrennt werden. Die Deque-Prüfpunkte helfen Prüfern, während der Barrierefreiheitsbewertungen konsistente und genaue Testergebnisse zu erzielen. Ein Prüfpunkt bezieht sich auf den relevantesten und anwendbarsten Abschnitt des Master-Listings der Deque-Prüfpunkte (und ihrer Anforderungen), die ein wichtiger Bestandteil des Deque-Wegs zur digitalen Gleichstellung sind.

Komponententests

Mit Cypress oder Playwright und Axe Watcher können Sie einzelne Komponenten (wie z. B. React-Komponenten) isoliert testen. Im Gegensatz dazu steht e2e-Tests, das die gesamte Webanwendung in ihrer realen Implementierung testet. Axe Developer Hub kann Barrierefreiheitsprobleme in End-to-End-Szenarien erkennen und Komponenten isoliert mit Cypress testen. Siehe e2e-Tests.

Konfigurationsüberschreibung

Eine Konfigurationsüberschreibung ermöglicht es Ihnen, Einstellungen für bestimmte Testrunden über die (JavaScript/TypeScript) configurationOverrides-Eigenschaft oder (Java) ConfigurationOverrides-Klasse in Ihrer Testkonfiguration anzupassen. Diese Überschreibungen müssen mit den globalen Konfigurationseinstellungen Ihrer Organisation übereinstimmen und können Änderungen an Barrierefreiheitsstandards, Best Practices, experimentellen Regeln und axe-core-Versionen enthalten.

Benutzerdefiniertes Regelset

Ein benutzerdefinierter Regelsatz wird aus einer JSON-Datei erstellt, die Regel-Daten (Regeln und Überprüfungen) enthält und an die Komponenten von Axe DevTools übergeben wird, um neue Regeln hinzuzufügen, die Schwere/den Einfluss einer Regel zu ändern oder eine Regel aus dem Test zu entfernen.

Duplikat

Ein Duplikat ist dasselbe Barrierefreiheitsproblem, das am selben Knoten des Document Object Models (DOM) in mehreren Seitenzustände auftritt. Wenn Sie ein Problem mit Duplikaten beheben, verschwinden alle Duplikate, da sie alle dasselbe Problem sind.

Zwei Ergebnisse werden als dasselbe Problem behandelt, wenn alle drei der folgenden Punkte übereinstimmen:

• Die Regel, die verletzt wurde.
• Das Element. Der Axe Developer Hub identifiziert das Element anhand seines CSS-Selectors und seines XPath, sowie durch seinen Ancestry-Selector, wenn ancestry aktiviert ist. Eine Übereinstimmung bei einem dieser Punkte reicht aus.
• Die URL der Seite, vollständig verglichen, einschließlich aller Abfragezeichenfolgen.

Nichts anderes wird verglichen. Insbesondere haben der Seitentitel und das HTML des Elements keinen Einfluss darauf, ob ein Ergebnis als Duplikat betrachtet wird.

Der gleiche Vergleich bestimmt, ob ein Problem als neu gilt: Ein Ergebnis, das mit nichts in der anwendbaren Baseline übereinstimmt, wird als neu gezählt. Das bedeutet, dass wenn sich die URL einer Seite oder ihre Element-Selektoren zwischen den Scans ändern, dasselbe zugrunde liegende Problem jedes Mal als neu gemeldet wird. Siehe Verwendung dynamischer Selektoren, um dies zu korrigieren.

e2e-Tests

End-to-End- oder e2e-Tests beziehen sich auf das Testen der Funktionalität der gesamten Webanwendung, indem deren reale Implementierung getestet wird. Mit Axe Developer Hub können Sie e2e-Szenarien auf Barrierefreiheitsprobleme testen und einzelne Komponenten isoliert mit Cypress testen. Siehe auch Komponententests.

Ereignis

Um die API- oder CLI-Nutzung zu überwachen, erstellt die Metrikbibliothek Ereignisse und sendet sie an den Nutzungsdienst. Ereignisse enthalten Informationen über die Nutzung, wie z. B. die Anzahl der während eines Webseiten-Scans verletzten Barrierefreiheitsregeln sowie das Datum und die Uhrzeit, zu der ein Barrierefreiheitsscan abgeschlossen wurde.

Experimentelle Regeln

Experimentelle Regeln werden noch entwickelt und getestet, um auf neue Technologien oder ein besseres Verständnis und Bewusstsein für Barrierefreiheitsprobleme zu reagieren. Diese Regeln sollten nicht in Produktionsumgebungen verwendet werden, da sie sich noch in der Entwicklung befinden und zu Fehlalarmen führen können. Schließlich könnten Regeln in diesem Regelset Teil von Barrierefreiheitsstandards werden. Experimentelle Regeln sind standardmäßig deaktiviert. Siehe Experimentelle Regeln für die Regeln, die dieses Regelset in der neuesten Version von axe-core ausmachen.

Flush

Die flush-Funktion schreibt Ihre Axe Watcher-Testergebnisse auf den Deque-Server und ist erforderlich, um sicherzustellen, dass die Ergebnisse vom Axe Developer Hub aufgezeichnet werden. Sie müssen die flush-Funktion in Ihrer Testsuite aufrufen.

Gitless

Gitless ist eine der beiden Datenformen, an die ein Developer Hub-Projekt gebunden werden kann: Die Testreihe des Projekts verwendet kein Git-Repository. Ein Projekt wird entweder auf Gitless oder Git basierend auf seiner ersten erfolgreichen Sitzung festgelegt; ein späterer Durchlauf mit der anderen Datenform wird abgelehnt, anstatt angenommen. Sie sind nicht verpflichtet, ein Git-Repository zu verwenden, aber ein Git-Repository ermöglicht es Ihnen, Barrierefreiheitsschäden mit spezifischen Codeänderungen zu verknüpfen, was bei ihrer Behebung hilft. Siehe Projektsperre.

Globale Konfiguration

Globale Konfiguration ist Teil von Axe-Konfiguration, die es Ihnen ermöglicht, verschiedene Optionen an einem Ort festzulegen, die zwischen verschiedenen Deque-Produkten geteilt werden. Ihr Administrator kann es erlauben, dass bestimmte Einstellungen von Benutzern geändert werden.

Identity Token

Ein Identity Token ist ein von JFrog ausgestelltes Sicherheitstoken, das Ihnen den Zugang zum Deque's Agora-Artefakt-Repository ermöglicht. Identity Tokens müssen zum Zeitpunkt der Erstellung kopiert werden, da dies die einzige Gelegenheit ist, darauf zuzugreifen. Sie laufen nach einem festgelegten Zeitintervall ab, typischerweise nach einem Jahr.

Auswirkung

Jeder Barrierefreiheitsverstoß wird einem Schweregrad zugeordnet. Der Schweregrad ist ein nützliches Maß, um die Priorisierung von Behebungsmaßnahmen zu unterstützen. Standardmäßig wird jeder Verstoßtyp von Deque-Barrierefreiheitsexperten einem Schweregrad zugewiesen. Diese Werte sind auf die meisten Situationen verallgemeinert, sodass Benutzer ihr Urteil nutzen können, um sie im Rahmen der Anpassung ihres Regelwerks zu ändern. Schwere oder kritische Schweregrade korrelieren damit, dass behinderte Nutzer auf signifikante oder unüberwindbare Nutzungsbarrieren stoßen. Diese tragen das höchste Maß an rechtlicher Haftung. Kleinere und moderate Probleme sind nicht so schwerwiegend, stellen aber dennoch wichtige Themen für behinderte Nutzer dar und erfordern eine Lösung, damit die Seite vollkommen konform ist. Die folgenden vier Stufen werden verwendet, um die Auswirkungen erkannter Barrierefreiheitsprobleme zu kategorisieren:

• Kritisch: Diese Auswirkung bedeutet, dass Benutzer mit einer Behinderung vollständig daran gehindert werden, auf ein Feature der Webseite zuzugreifen oder es zu nutzen. Bis eine Lösung implementiert wird, bleibt der Inhalt völlig unzugänglich. Dies macht Ihre Organisation sehr anfällig für Klagen. Die Behebung kritischer Probleme sollte höchste Priorität haben.

• Schwerwiegend: Diese Auswirkung bedeutet, dass Benutzer mit einer Behinderung auf erhebliche Hürden stoßen, wenn sie die Website nutzen. Diese Benutzer werden erhebliche Frustrationen erleben, wenn sie versuchen, auf verwandte Inhalte zuzugreifen. Bis eine Lösung implementiert wird, wird es schwierig oder unmöglich sein, auf einige Inhalte zuzugreifen, was Ihre Organisation anfällig für rechtliche Schritte macht. Die Behebung sollte eine hohe Priorität haben.

• Moderat: Diese Auswirkung bedeutet, dass einige Barrieren für Benutzer mit einer Behinderung bestehen, sie jedoch nicht daran hindern würden, auf grundlegende Abläufe oder Inhalte zuzugreifen. Probleme mit Auswirkungen auf diesem Niveau können Ihre Organisation für rechtliche Schritte anfällig machen. Sie müssen gelöst werden, bevor eine Seite vollständig konform ist, und sollten behoben werden.

• Geringfügig: Ein Problem, das weniger Auswirkungen auf behinderte Benutzer hat als ein moderates Problem. Das Problem kann eine geringere Priorität haben als moderate, schwerwiegende und kritische Probleme, muss jedoch trotzdem gelöst werden, damit eine Seite vollständig konform ist.

Unvollständig

Ein unvollständig-Ergebnis bedeutet, dass axe-core nicht mit vollständiger Sicherheit bestimmen konnte, ob etwas ein Verstoß ist, daher muss es von einem Menschen überprüft werden. Da axe-core keine Fehlalarme generieren möchte, meldet es nur die Probleme als Verstöße, bei denen es sich sicher ist, und zeichnet alles, was unsicher ist, separat auf. Unvollständig und muss überprüft werden sind zwei Bezeichnungen für denselben Ergebnistyp; welche Sie sehen, hängt von der Axe DevTools-Komponente ab, die Sie verwenden. Ein unvollständiges Ergebnis kann, muss aber kein Problem der Barrierefreiheit darstellen.

Intelligente geführte Tests (IGT)

Intelligent Guided Testing (IGT) ist eine interaktive Komponente für Barrierefreiheitstests der Erweiterungen des Axe DevTools-Webbrowsers, die entwickelt wurde, um Barrierefreiheitsfehler zu finden, die in automatisierten Tests nicht erkannt werden können. IGT stellt dem Benutzer einfache Fragen zur zu testenden Webseite und verwendet dieses Feedback, um mehr Barrierefreiheitsfehler zu lokalisieren, als dies sonst mit automatisierten Tests möglich wäre. Weitere Informationen zu Intelligent Guided Tests finden Sie unter Dokumentation zu intelligenten geführten Tests.

Problem

Ein Verstoß gegen Barrierefreiheitsrichtlinien (wie definiert durch Standards wie WCAG 1.0, WCAG 2.0, Section 508 und WAI-ARIA), der im Code einer Webseite oder Webanwendung identifiziert wird.

JSON-Barrierefreiheits-Ergebnisse

Wenn Sie eine Website auf Barrierefreiheitsprobleme testen, indem Sie die APIs oder die CLI von Axe DevTools verwenden, werden Ihre Ergebnisse als JSON-Datei gespeichert, die in der Dokumentation als JSON-Barrierefreiheitsergebnisse-Datei bezeichnet wird. Sie können diese Datei in Axe Reports hochladen (wodurch Sie die Barrierefreiheit Ihrer Website im Laufe der Zeit über die Axe Reports-Website überwachen können). Sie können die JSON-Datei mit Barrierefreiheits-Ergebnissen auch lokal in .csv, .xml oder .html konvertieren, indem Sie die CLI verwenden. Weitere Informationen finden Sie unter Berichterstellung mit der CLI. Alternativ ermöglichen die APIs auch die Umwandlung von JSON-Dateien mit Barrierefreiheits-Ergebnissen in Berichte während eines Testlaufs (siehe unten Berichterstattung für weitere Informationen).

Manueller Modus

Standardmäßig analysiert Axe Developer Hub jede Ihrer Webseiten automatisch und analysiert sie erneut, sobald ein neuer Seitenstatus erkannt wird. Sie können dieses automatische Verhalten deaktivieren, indem Sie

• (JavaScript/TypeScript) Das Setzen der autoAnalyze-Eigenschaft auf dem axe-Konfigurationsobjekt auf false.
• (Java) Der Aufruf der setAutoAnalyze()-Methode mit false.

Sie können auch das automatische Analyseverhalten überschreiben, indem Sie

• (JavaScript/TypeScript) Die stop()-Methode aufrufen.
• (Java) Die AxeWatcherController.stop()-Methode aufrufen.

In beiden Fällen versetzt dies den Watcher in den manuellen Modus. Im manuellen Modus werden Seiten nur analysiert, wenn Sie die analyze()-Methode aufrufen.

Metrikbibliothek

Eine interne Bibliothek, die von Deque's APIs und CLI verwendet wird, um Nutzungsinformationen an den Nutzungsdienst zu melden.

Modifiziertes Test-Suite

Ein modifizierte Testsuite ist eine Testsuite, die Sie gemäß den Anweisungen des Axe Developer Hub geändert haben, als Sie ein neues Projekt erstellt haben. Durch die Modifikation Ihrer Testsuite können Sie Barrierefreiheitstests mit minimalen Änderungen an Ihrer bestehenden Testsuite hinzufügen.

Muss überprüft werden

Ein Problem erfordert die Überprüfung durch einen Menschen, um festzustellen, ob es sich um einen tatsächlichen Verstoß gegen die Barrierefreiheitsstandards handelt. Muss überprüft werden bedeutet dasselbe wie unvollständig: axe-core konnte nicht mit vollständiger Sicherheit feststellen, ob das Problem ein Verstoß ist. Wenn Sie neu im Bereich des Barrierefreiheitstests sind oder an einer Website mit vielen bekannten Problemen arbeiten, sollten Sie zuerst die Verstöße bearbeiten. Wenn Sie zu den Ergebnissen gelangen, die überprüft werden müssen, ziehen Sie einen Experten für digitale Barrierefreiheit hinzu, bevor Sie entscheiden, ob Sie sie beheben oder ignorieren.

Seitenstatus

Der Seitenstatus einer Webseite bezieht sich auf den Zustand ihres Dokumentobjektmodells (DOM) zu einem bestimmten Zeitpunkt. Seitenstatus sind nützlich für komplexe Websites mit Anmeldebildschirmen oder dynamischen Benutzeroberflächen wie Single-Page-Applications (SPAs). Beispiele für den DOM-Zustand umfassen:

• Die Sichtbarkeit von Elementen
• Die Inhalte von Elementen
• Der Überprüfungsstatus von Radiobuttons und Kontrollkästchen

Das Watcher-Paket untersucht Webseiten erneut, wenn es Änderungen im DOM feststellt, und speichert jedes Mal einen neuen Seitenstatus.

Projekt

Ein Projekt im Axe Developer Hub enthält Barrierefreiheitsergebnisse, Informationen zu den Testläufen und Git-Daten (Branches und Commits). Die Zuordnung zwischen diesen Informationen und dem Projekt erfolgt über die Projekt-ID des Projekts. Wenn Sie ein neues Projekt im Axe Developer Hub erstellen und benennen, wird eine Projekt-ID generiert, die Sie mit Ihren Tests verwenden, um das Projekt zu identifizieren.

Berichterstattung

Berichterstellung bezieht sich auf das Hochladen einer JSON-Barrierefreiheitsergebnisse-Datei in Axe Reports oder das lokale Konvertieren in einen Bericht (eine .csv-, .xml- oder .html-Datei) zur Verwendung in einer anderen Anwendung.

RGAA

RGAA, oder Référentiel Général d'Amélioration de l'Accessibilité, ist der Web-Barrierefreiheitsstandard der französischen Regierung. Er basiert weitgehend auf den WCAG 2.1 und bietet spezifische technische Kriterien zur Bewertung der Barrierefreiheit von Webinhalten. Die derzeit unterstützte Version ist RGAA 4, identifiziert durch die Regelset-ID rgaav4.

Regel

Eine Regel entspricht einem Erfolgskriterium der Barrierefreiheitsrichtlinien. Sie sind durch JSON-Objektdateien definiert und enthalten eine ID, eine Beschreibung und Metadaten zur Hilfe sowie einen oder mehrere Prüfungen und optionale Parameter.

Section 508

Eine Änderung des Rehabilitationsgesetzes der Vereinigten Staaten von 1973, die von Bundesbehörden verlangt, ihre elektronische und Informationstechnologie für Menschen mit Behinderungen zugänglich zu machen. Sie umfasst sechzehn Bestimmungen, die auf Zugangsrichtlinien basieren, die von den Web Content Accessibility Guidelines (WCAG) des World Wide Web Consortium (W3C) entwickelt wurden, aber nicht identisch mit den WCAG 1.0 oder 2.0 Standards sind.

SHA

Wenn Sie einen Git-Commit erstellen, wird eine ID generiert, die den Commit eindeutig identifiziert. Diese eindeutige ID wird SHA genannt (eine Abkürzung für die Secure Hash Algorithms, eine Gruppe kryptographischer Hash-Funktionen).

Verwendungsservice

Ein REST-Webdienst, der Nutzungsmetriken für Axe DevTools für Web (APIs und die CLI) aufzeichnet. Es handelt sich entweder um den von Deque bereitgestellten öffentlichen Dienst oder um Ihren eigenen Dienst. Weitere Informationen finden Sie unter Der Nutzungsdienst von Axe DevTools für Web.

Verstoß

Ein von Axe DevTools identifiziertes Problem, das gegen eine oder mehrere Barrierefreiheitsstandards verstößt.

Watcher

Die Codekomponente, die Sie in Ihre Testsuite integrieren, wird Watcher genannt. Deque bietet mehrere Editionen des Pakets für die unterstützten Sprachen und Test-Frameworks an. Sie integrieren das Watcher-Paket in Ihre Website-Testsuite, um Webseiten zu analysieren und die Ergebnisse an Axe Developer Hub zu melden, wo Sie die Ergebnisse einsehen können. Das Watcher-Paket scannt außerdem das aktuelle Git-Commit und den Branch und verknüpft die Testläufe damit.

WCAG

WCAG, oder Web Content Accessibility Guidelines, wurden vom World Wide Web Consortium (W3C) entwickelt und erklären, wie Webinhalte für Menschen mit Behinderungen zugänglicher gemacht werden können. WCAG 1.0 wurde im Mai 1999 veröffentlicht. WCAG 2.0 wurde im Dezember 2008 veröffentlicht. WCAG 2.0 ist breit anwendbar auf fortgeschrittenere Technologien und lässt sich präziser mit automatisierten Tests und menschlicher Bewertung testen. WCAG 2.1 wurde im Juni 2018 veröffentlicht. Diese Richtlinien enthalten Erfolgskriterien, die testbare Kriterien für spezifische Elemente definieren. WCAG 2.2, die aktuellste Version der Richtlinien, wurde 2023 veröffentlicht und bietet neun neue Erfolgskriterien gegenüber WCAG 2.1.

Wrapping

Wrapping bezieht sich darauf, eine Browser-Automatisierungsplattform (wie Cypress) zu modifizieren, um Barrierefreiheitstestcode (im Watcher-Paket) aufzurufen, wann immer eine Funktion der Browser-Automatisierungsplattform verwendet wird. Wrapping ermöglicht es Ihnen, Barrierefreiheitstests mit minimalen Änderungen am Code in Ihre bestehenden Testsuiten zu integrieren.