Axe Developer Hub Glossar

a11y

Zahlenbasierte Abkürzung (oder Numeronym) für das Wort „Barrierefreiheit“, wobei „11“ (elf) die Anzahl der Zeichen zwischen dem Anfangs-„a“ und dem End-„y“ in Barrierefreiheit darstellt. Ausgesprochen als ally.

API-Schlüssel

Für die Autorisierung erstellen Sie einen API-Schlüssel in den Axe Konto-Einstellungen. Sie können denselben API-Schlüssel für mehrere Projekte verwenden, wobei Sie jedoch einen Axe Developer Hub API-Schlüssel nur für Webprojekte und einen Axe DevTools Mobile API-Schlüssel nur für mobile Projekte verwenden dürfen.

Behandeln Sie Ihren API-Schlüssel als geheimes Anmeldeinformationen: Fügen Sie ihn nicht der Versionskontrolle hinzu oder teilen Sie ihn, und speichern Sie ihn in einer Umgebungsvariable oder im Geheimnismanager Ihrer CI/CD-Plattform.

Axe Developer Hub

Axe Developer Hub ermöglicht Ihnen, neue Testprojekte zu erstellen und zeigt Ihnen die Ergebnisse Ihrer Barrierefreiheitstests. Sie können so viele Projekte erstellen, wie Sie benötigen, um Barrierefreiheit auf Ihren Webseiten und mobilen Apps anzuzeigen und zu verwalten.

Baseline

Eine Basislinie ist der frühere Scan, den Developer Hub konstant hält, damit ein Vergleich messen kann, was sich geändert hat. Welcher Scan als Basislinie dient, hängt von der Art des Vergleichs ab: Ein vergleich zwischen Zweigen verwendet den neuesten Pipeline-Lauf auf dem Standardzweig, und ein vergleich innerhalb eines Zweiges, zusammen mit dem GitHub-Aktion, verwendet den Scan vom vorherigen Commit, der Ergebnisse auf demselben Zweig hat.

Best Practices

Deque Best Practices sind erprobte Techniken, die gewünschte Barrierefreiheitsergebnisse liefern, wenn spezifische formale Methoden fehlen oder unzureichend sind. Obwohl sie nicht offiziell in bestehenden Barrierefreiheitsrichtlinien 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 Nicht-Einhaltung der Best Practices von Deque nicht automatisch auf ein Versagen hinweist. Zudem ist eine fachkundige Beurteilung erforderlich, um die Angemessenheit im Kontext der Ziele der Anwendung, der Seite oder des Projekts zu berücksichtigen. Manchmal ist die bestmögliche Barrierefreiheitstechnik nicht anwendbar oder praktisch, um ein spezifisches Problem zu lösen. Siehe Best Practices für die Regeln, die das Best Practices-Regelset bilden.

Build-ID

Der Build-ID wird automatisch als UUID generiert, wenn er nicht vom Nutzer bereitgestellt wird, und wird verwendet, um Scans als einzelne Testsitzung zu verknüpfen. Wenn Sie eine Testreihe über mehrere Maschinen oder Umgebungen hinweg ausführen, wird durch Bereitstellung einer Build-ID all diese Durchläufe zusammen verknüpft und als einzelne Sitzung im Developer Hub angezeigt.

Vergleich zwischen Zweigen

Ein vergleich zwischen Zweigen vergleicht den neuesten Scan eines Zweigs mit dem neuesten Pipeline-Lauf auf dem Standardzweig des Projekts. Er erscheint in der Ansichtsoption „Zweige“ und zeigt, was sich ändern würde, wenn der Zweig jetzt zusammengeführt würde.

Datenstruktur

Die Datenstruktur eines Projekts ist entweder Git oder Gitless: ob seine Ergebnisse Git-Informationen (Repository, Branch und Commit) enthalten oder nicht. Die Datenstruktur eines Projekts wird durch seine Projektsperre festgelegt.

Duplikat

Ein Duplikat ist dasselbe Barrierefreiheitsproblem, das auf demselben Knoten des Dokumentobjektmodells (DOM) in mehreren Seitenzuständen angezeigt wird. 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 übereinstimmen:

• Die Regel, die verletzt wurde.
• Das Element. Axe Developer Hub identifiziert das Element anhand seines CSS-Selectors und seines XPath sowie durch seinen Vorfahren-Selector, wenn ancestry aktiviert ist; eine Übereinstimmung mit einem dieser Kriterien genügt.
• 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 behandelt wird.

Entdoppelung gilt derzeit nur für Webprojekte. Mobile Ergebnisse haben keinen CSS-Selector, daher passt dieser Vergleich nie, und jedes mobile Ergebnis wird bei jedem Vergleich als neu behandelt, ohne Einstellmöglichkeit dafür.

Dieselbe Vergleichsmethode bestimmt, ob ein Web-Ergebnis neu ist: Ein Ergebnis, das mit keinem in der anwendbaren Basislinie übereinstimmt, wird als neu gezählt. Siehe Warum werden dieselben Probleme immer wieder als neu gemeldet?, um dies zu korrigieren.

e2e-Tests

End-to-End-Tests oder e2e-Tests beziehen sich auf das Testen der gesamten Funktionalität einer Webanwendung durch Testen ihrer realen Umsetzung. Mit Axe Developer Hub können Sie End-to-End-Szenarien auf Barrierefreiheitsprobleme testen.

Experimentelle Regeln

Experimentelle Regeln werden noch entwickelt und getestet, um auf neue Technologien oder ein gestiegenes 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. Letztendlich 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.

Git

Git ist eine Datenstruktur, an die ein Projekt im Developer Hub gesperrt werden kann: Die Test-Suite des Projekts verwendet ein Git-Repository. Die Nutzung von Git ermöglicht es, Zugänglichkeitsmängel mit Code auf verschiedenen Branches und in spezifischen Commits zu verknüpfen, was bei deren Lösung hilft.

Gitless

Gitless ist die andere Datenstruktur, an die ein Projekt im Developer Hub gesperrt werden kann: Die Test-Suite des Projekts verwendet kein Git-Repository. Obwohl nicht erforderlich, ermöglicht ein Git-Repository es, Zugänglichkeitsmängel mit spezifischen Codeänderungen zu verknüpfen, was bei deren Lösung hilft.

Auswirkung

Ein Auswirkungs-Level wird jedem Barrierefreiheitsverstoß zugewiesen und ist in vier Stufen von geringsten bis zu erheblichsten Auswirkungen eingeteilt: geringfügige, moderate, ernst und kritisch. Diese Metrik hilft, die Bemühungen zur Behebung zu priorisieren, und Deque-Barrierefreiheitsexperten weisen jedem Verstoßtyp standardmäßig ein Auswirkungslevel zu.

Defekte mit ernst- oder kritisch-Auswirkungslevel stellen signifikante oder unüberwindbare Barrieren für Benutzer mit Behinderungen dar und haben das höchste juristische Haftungsrisiko. Während geringfügige- und moderate-Probleme nicht so schwerwiegend sind, sind sie dennoch entscheidend für die Einhaltung von Vorschriften und die Bedürfnisse von Menschen mit Behinderungen.

Die vier Stufen zur Kategorisierung der Auswirkungen von Zugänglichkeitsproblemen sind:

1. Geringfügig: Probleme, die Benutzer mit Behinderungen weniger stark beeinträchtigen als moderatere Probleme, aber dennoch zur vollständigen Einhaltung gelöst werden müssen.

2. Moderat: Einige Barrieren bestehen für Benutzer mit Behinderungen, die sie jedoch nicht daran hindern würden, auf grundlegende Inhalte oder Abläufe zuzugreifen. Diese Probleme könnten Ihre Organisation für rechtliche Schritte anfällig machen und sollten behoben werden, bevor vollständige Compliance erreicht wird.

3. Ernst: Benutzer mit Behinderungen werden beim Interagieren mit der Seite auf erhebliche Barrieren stoßen, was zu Frustration und Schwierigkeiten beim Zugriff auf verwandte Inhalte führen wird. Die Behebung sollte oberste Priorität haben, um rechtliche Schritte zu vermeiden.

4. Kritisch: Benutzer mit Behinderungen sind vollständig daran gehindert, auf ein Feature der Webseite zuzugreifen oder damit zu interagieren, wodurch die Inhalte unzugänglich werden und Ihre Organisation einem hohen Risiko von rechtlichen Klagen ausgesetzt ist. Die Behebung kritischer Probleme sollte oberste Priorität haben.

Modifizierte Test-Suite

Ein modifizierte Test-Suite ist eine Testsuite, die Sie gemäß den Anweisungen, die vom Axe Developer Hub bei der Erstellung eines neuen Projekts bereitgestellt werden, geändert haben. Durch das Anpassen Ihrer Testsuite können Sie Barrierefreiheitstests mit minimalen Änderungen an der Testsuite selbst in Ihre bestehende Testsuite einfügen.

Muss Überprüft Werden

Ein Muss Überprüft Werden-Ergebnis ist eines, bei dem axe-core nicht mit Sicherheit feststellen konnte, ob es sich um einen Verstoß handelt, sodass eine Person es inspizieren muss. Siehe Muss Überprüft Werden im Glossar des Axe DevTools für Web für die vollständige Definition. Der Axe Developer Hub zeigt in seiner Benutzeroberfläche keine Ergebnisse an, die als „Muss Überprüft Werden“ markiert sind, und berücksichtigt sie weder bei der Gesamtanzahl der Probleme noch bei der Barrierefreiheitsbewertung. Sie erscheinen nur im Axe Universal JSON-Export und in den vollständigen Ergebnissen, die von der Sitzungen und Ergebnisse API zurückgegeben werden.

Organisationsadministrator

Ein Organisationsadministrator (Org-Admin) ist ein Benutzer mit administrativen Rechten für sein gesamtes Unternehmen im Axe-Konto. Org-Admins können alle Projekte in ihrem Unternehmen einsehen und Projekteinstellungen sowie Mitglieder verwalten, unabhängig davon, ob sie Teil eines bestimmten Projekts sind. Der Status als Org-Admin hat Vorrang vor projektbezogenen Rollen. Org-Admins müssen über eine aktive Axe Developer Hub oder Axe DevTools for Mobile Lizenz verfügen, um neue Projekte zu erstellen oder Ergebnisse an die Projekte zu senden, denen sie im Axe Developer Hub angehören, können jedoch bestehende Projekte auch ohne Lizenz verwalten.

Seitenstatus

Der Seitenstatus bezieht sich auf den Zustand des Dokumentobjektmodells (DOM) einer Webseite zu einem bestimmten Zeitpunkt. Das Anzeigen verschiedener Seitenzustände ist hilfreich für komplexe Webseiten mit Anmeldebildschirmen oder dynamischen Benutzeroberflächen, wie Einzelseiten-Anwendungen (SPAs). Beispiele für DOM-Zustände umfassen:

• Die Sichtbarkeit der Elemente
• Der Inhalt von Elementen
• Der ausgewählte Zustand von Optionsfeldern und Kontrollkästchen

Beim Einsatz von Watcher durchsucht das Paket Webseiten erneut, wann immer es Änderungen im DOM erkennt, und speichert jedes Mal einen neuen Seitenzustand.

Pipeline-Lauf

Ein Pipeline-Lauf ist ein Scan, der durch einen CI/CD-Pipeline ausgelöst wird, anstatt durch einen lokalen Lauf von der Maschine eines Entwicklers. Developer Hub kennzeichnet Pipeline-Läufe separat, damit immer klar ist, welcher Scan eines Zweigs autoritativ ist. Ein Pipeline-Lauf auf dem Standardzweig des Projekts ist erforderlich, damit Vergleiche zwischen Zweigen eine Basislinie haben; ohne einen solchen wird jedes Problem als neu gemeldet. Siehe Pipeline-Informationen und Axe-Watcher in Continuous Integration (CI) Umgebungen.

Projekt

Ein Projekt im Axe Developer Hub enthält Zugänglichkeitsergebnisse, Informationen zum Testrun und Git-Daten (Branches und Commits). Sie erstellen und benennen ein neues Projekt im Developer Hub, das eine Projekt-ID erzeugt, die für Ihre Tests verwendet wird, um das Projekt zu identifizieren und Ergebnisdaten mit dem Projekt zu verknüpfen. Sobald ein Projekt seine erste erfolgreiche Sitzung aufgenommen hat, sind seine Datenstruktur und, für Git-Projekte, sein Repository durch seine Projektsperre festgelegt.

Projektadministrator

Ein Projektadministrator ist ein Projektmitglied mit erweiterten Berechtigungen. Projekt-Admins können alles tun, was ein Projektmitglied kann, zusätzlich zu der Verwaltung von Projekteinstellungen, dem Hinzufügen oder Entfernen von Mitgliedern und dem Ändern von Mitgliederrollen. Bei Verwendung von Axe Watcher ist der API-Schlüssel eines Projekt-Admins erforderlich, um Tests in einer Pipeline auszuführen.

Projekt-ID

Eine Projekt-ID wird automatisch generiert, wenn Sie ein neues Projekt hinzufügen, um Ihre Ergebnisdaten mit diesem Projekt zu verknüpfen. Sowohl eine Projekt-ID als auch ein API-Schlüssel sind erforderlich, um Zugänglichkeitsresultate an den Developer Hub zu senden. Mappen Sie eine Projekt-ID auf eine Test-Suite/Repository: Dies wird durch die Projektsperre erzwungen, die die Datenstruktur und das Repository eines Projekts nach seiner ersten erfolgreichen Sitzung festlegt.

Projektsperre

Sobald ein Projekt seine erste erfolgreiche Sitzung aufgenommen hat, Sperren es sich auf die Datenstruktur dieser Sitzung und, für Git-Projekte, auf das Repository dieser Sitzung. Ein gesperrtes Projekt lehnt jeden späteren Durchlauf mit einer anderen Datenstruktur oder einem anderen Repository bei der Aufnahme ab; die Ergebnisse werden nicht gespeichert. Die Projekteinstellungen zeigen die gesperrte Datenstruktur und das Repository als schreibgeschützt an. Siehe Ausführung abgelehnt: Datenstruktur oder Repository widerspricht dem Projekt.

Projektmitglied

Ein Projektmitglied ist ein Benutzer, der zu einem Axe Developer Hub-Projekt hinzugefügt wurde. Projektmitglieder können Tests ausführen und Ergebnisse innerhalb des Projekts einsehen. Mitglieder müssen über eine aktive Lizenz verfügen, um auf das Projekt zuzugreifen.

Scan

Ein Scan sind die Barrierefreiheits-Ergebnisse, die Developer Hub durch das Testen Ihres Produkts erhält, und was ein einzelner Scan abdeckt, variiert je nach Projekttyp.

Für Webprojekte ist ein Scan die vollständige Ergebnismenge, die Ihr Test-Suite in einem Durchlauf produziert, unabhängig davon, wie viele Seiten es dabei besucht, und wird an Developer Hub übermittelt über Axe Watcher, die Axe DevTools für Web CLI oder die Web-APIs, die über die CLI hochladen. Jede Seite, die überprüft wird, kann ein oder mehrere Seitenzuständen ergeben, je nach dem erkannten DOM-Zustand, wie z. B. wenn eine Einzelanwendungsseite den Zustand ändert, ohne die Seite neu zu laden; der Scan ist die gesamte Sammlung von Seitenzuständen aus diesem Lauf.

Für Mobile Projekte ist ein Scan das Ergebnis des Testens eines einzelnen App-Bildschirms mit dem Axe DevTools Mobile Analyzer. Das Testen mehrerer Bildschirme in einer Sitzung führt zu mehreren Scans, die unter einer Sitzung zusammengefasst werden.

SHA

Wenn Sie einen Commit mit Git erstellen, wird eine ID generiert, um den Commit eindeutig zu identifizieren. Diese eindeutige ID wird als SHA bezeichnet (benannt nach den Secure Hash Algorithms, einer Gruppe kryptographischer Hash-Funktionen).

Tag

Ein Tag gruppiert Regeln zusammen, die zu einer spezifischen Barrierefreiheitsrichtlinie gehören, wie WCAG. Für weitere Informationen zu den Regeln und den Tags, denen diese Regeln angehören, siehe axe-core Regelsbeschreibungen

WCAG

WCAG oder Richtlinien für die Barrierefreiheit von Webinhalten sind eine Reihe von Richtlinien, die vom World Wide Web Consortium (W3C) entwickelt wurden, um Webinhalte für Menschen mit Behinderungen zugänglicher zu machen. Diese Richtlinien bieten einen Rahmen zur Erstellung barrierefreier Websites und digitaler Inhalte, die von Menschen mit einer Vielzahl von Behinderungen genutzt werden können.

Die drei Konformitätsstufen der WCAG werden durch eine Reihe von Erfolgskriterien definiert, die spezifische Elemente von Webinhalten beschreiben, die erfüllt werden müssen, um diese Konformitätsstufe zu erreichen. Konformitätsstufe A ist die Mindestkonformität, während Konformitätsstufe AAA die strengste ist. Konformitätsstufe AA erfordert die Einhaltung sowohl der Erfolgskriterien der Stufen A als auch AA. Die Konformität mit allen drei Erfolgskriterienstufen (A, AA und AAA) ist erforderlich, um die Konformität mit Stufe AAA zu erreichen.

WCAG 1.0 war die erste Version dieser Richtlinien und wurde 1999 veröffentlicht. WCAG 2.0 wurde 2008 veröffentlicht und bot umfassendere Richtlinien, um Webinhalte für Menschen mit einem breiteren Spektrum von Behinderungen zugänglich zu machen.

WCAG 2.1 wurde 2018 veröffentlicht. Sie baut auf den vorherigen Versionen auf und enthält neue Erfolgskriterien, um Barrierefreiheitsprobleme zu adressieren, die seit der Veröffentlichung von WCAG 2.0 aufgetreten sind. WCAG 2.1 bietet auch mehr Anleitungen zur mobilen Barrierefreiheit, Barrierefreiheit für Menschen mit Sehbehinderungen und kognitive und Lernbehinderungen.

WCAG 2.2, die neueste Iteration dieser Richtlinien, wurde 2023 veröffentlicht und bietet neun neue Erfolgskriterien gegenüber WCAG 2.1. Sie liefert verbesserte Anleitungen zur Berücksichtigung der Bedürfnisse von Nutzern mit kognitiven oder Lernbehinderungen, Nutzern mit Sehschwäche und Nutzern mit Behinderungen auf mobilen Geräten. Sie ist rückwärtskompatibel mit WCAG 2.1.

Vergleich innerhalb eines Zweiges

Ein vergleich innerhalb eines Zweiges vergleicht den Scan eines Commits mit dem Scan des vorherigen Commits, der Ergebnisse auf demselben Zweig hat. Er erscheint in der Ansicht „Commits“ und zeigt, was ein bestimmtes Commit eingeführt oder behoben hat.