axe Developer Hub Glossar

a11y

Zahlenbasierte Abkürzung (oder Numeronym) für Barrierefreiheit , wobei 11 (elf) die Anzahl der Zeichen zwischen dem Anfangs- B und dem End- t in Barrierefreiheit darstellt. Ausgesprochen ally.

API-Schlüssel

Ein API-Schlüssel wird vom axe Developer Hub erstellt, wenn Sie ein neues Projekt erstellen. Der Schlüssel verknüpft Testläufe und deren Ergebnisse mit einem gegebenen Projekt. Es muss in der Testsuite festgelegt werden, damit die Ergebnisse einem bestimmten Projekt zugeordnet werden können.

axe Developer Hub

axe Developer Hub ermöglicht Ihnen die Erstellung neuer Testprojekte und zeigt Ihnen die Ergebnisse Ihrer Barrierefreiheits-Testläufe. Sie können die Ergebnisse nach Datum, Sitzungs-ID und Schweregrad filtern. Sie können Ihre Barrierefreiheitsergebnisse überwachen und nach Sitzungs-ID gruppieren. Sie können so viele Projekte erstellen, wie Sie zum Überwachen verschiedener Websites benötigen.

Das @axe-core/watcher paket

Sie integrieren das @axe-core/watcher Paket in Ihre Website-Testsuite, um Webseiten zu analysieren und die Ergebnisse an den axe Developer Hub zu melden, wo Sie die Ergebnisse anzeigen können. Das @axe-core/watcher Paket scannt außerdem das aktuelle Git-Commit und den aktuellen Branch und verknüpft Testläufe mit dem aktuellen Commit. Beim Testen Ihrer Website wird vom Paket @axe-core/watcher nur Google Chrome unterstützt. Siehe Systemanforderungen.

Beste Praktiken

Deque Best Practices sind bewährte Techniken, die die gewünschten Zugänglichkeitsergebnisse liefern, wenn bestimmte formale Methoden fehlen oder unzureichend sind. Obwohl sie nicht offiziell in etablierten Regelwerken zur Barrierefreiheit enthalten sind, kann die Befolgung der Best Practices von Deque die Barrierefreiheit und die Gesamtqualität der getesteten Webseite verbessern. Zu beachten ist, dass die Nichteinhaltung der Best Practices von Deque nicht automatisch einen Fehler bedeutet. Darüber hinaus ist eine fachkundige Beurteilung erforderlich, um die Eignung im Kontext der Site- oder Seitenziele zu beurteilen. Manchmal ist die bewährte Barrierefreiheitstechnik zur Lösung eines bestimmten Problems nicht anwendbar oder praktikabel. Siehe Best Practices für die Regeln, die den Best-Practice-Regelsatz bilden.

Browser-Automatisierungsplattform

Eine Browser-Automatisierungsplattform ist ein Framework, mit dem Sie Ihre Website-Tests automatisieren können. 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

Komponentenprüfung

Mit Cypress oder Playwright können Sie einzelne Komponenten (z. B. React-Komponenten) isoliert testen. Vergleichen Sie dies mit e2e-Tests, bei denen die gesamte Webanwendung in ihrer realen Implementierung getestet wird. Axe Developer Hub kann Zugänglichkeitsprobleme nur in End-to-End-Szenarien erkennen und ist nicht dafür ausgelegt, Komponenten isoliert zu testen. Siehe End-to-End-Tests.

Konfigurationsüberschreibung

Eine Konfigurationsüberschreibung ermöglicht Ihnen die Anpassung von Einstellungen für bestimmte Testläufe über die Eigenschaft configurationOverrides in Ihrer Testkonfiguration. Diese Überschreibungen müssen den globalen Konfigurationseinstellungen Ihrer Organisation entsprechen und können Änderungen an Zugänglichkeitsstandards, Best Practices, experimentellen Regeln und Axe-Core-Versionen umfassen.

Duplikat

Ein Duplikat ist dasselbe Zugänglichkeitsproblem, das im selben Document Object Model (DOM)-Knoten in mehreren Seitenzuständen auftritt. Wenn Sie ein Problem mit Duplikaten beheben, verschwinden alle Duplikate, da es sich bei allen um dasselbe Problem handelt.

e2e-Tests

Beim End-to-End-Test oder e2e-Test geht es darum, die Funktionalität der gesamten Webanwendung zu überprüfen, indem ihre Implementierung in der realen Welt getestet wird. Mit dem axe Developer Hub können Sie e2e-Szenarien auf Zugänglichkeitsprobleme testen, jedoch nicht einzelne Komponenten isoliert testen, wie es Cypress und Playwright anbieten. Siehe auch Komponententest.

Experimentelle Regeln

Es werden noch immer experimentelle Regeln entwickelt und getestet, um neuen Technologien oder einem besseren Verständnis und Bewusstsein für Barrierefreiheitsthemen anzugehen. In Produktionsumgebungen sollte man sich nicht auf diese Regeln verlassen, da sie sich noch in der Entwicklung befinden und Fehlalarme auftreten können. Die Regeln dieses Regelsatzes könnten schließlich Teil der Zugänglichkeitsstandards werden. Experimentelle Regeln sind standardmäßig deaktiviert. Sehen Sie sich Experimentelle Regeln an, um die Regeln zu finden, aus denen dieser Regelsatz in der neuesten Version von axe-core besteht.

Leeren

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

Gitless

Gitless bezieht sich auf die Verwendung des Pakets @axe-core/watcher ohne ein Git-Repository. Sie müssen kein Git-Repository verwenden, aber ein Git-Repository ermöglicht Ihnen, Zugänglichkeitsmängel bestimmten Codeänderungen zuzuordnen und so bei ihrer Behebung zu helfen.

Globale Konfiguration

Die globale Konfiguration ist Teil der axe-Konfiguration , mit der Sie verschiedene Optionen an einem Ort festlegen können, die zwischen verschiedenen Deque-Produkten gemeinsam genutzt werden können. Ihr Administrator kann zulassen, dass Benutzer bestimmte Einstellungen ändern.

Auswirkung

Jedem Verstoß gegen die Barrierefreiheit wird eine Auswirkungsstufe zugewiesen. Die Auswirkungsstufe ist in vier Stufen unterteilt, von der geringsten bis zur größten Auswirkung: geringfügig, mittelschwer, schwerwiegend und kritisch. Mithilfe dieser Kennzahl können Sie die Abhilfemaßnahmen priorisieren. Die Barrierefreiheitsexperten von Deque weisen jedem Verstoßtyp standardmäßig eine Auswirkungsstufe zu.

Mängel mit der Auswirkungsstufe schwerwiegend oder kritisch stellen für Benutzer mit Behinderungen erhebliche oder unüberwindbare Barrieren dar und führen zu der höchsten rechtlichen Haftung. Auch wenn geringfügige und mittelschwere Probleme nicht ganz so schwerwiegend sind, sind sie dennoch von entscheidender Bedeutung für die Einhaltung der Vorschriften und die Berücksichtigung der Bedürfnisse von Menschen mit Behinderungen.

Die vier Ebenen, die zur Kategorisierung der Auswirkungen von Barrierefreiheitsproblemen verwendet werden, sind:

1. Geringfügig: Probleme, die Benutzer mit Behinderungen weniger als mittelschwere Probleme betreffen, für die vollständige Konformität jedoch dennoch eine Lösung erfordern.

2. Moderat: Für Benutzer mit Behinderungen bestehen einige Barrieren, die sie jedoch nicht am Zugriff auf grundlegende Inhalte oder Abläufe hindern. Diese Probleme können Ihr Unternehmen anfällig für rechtliche Schritte machen und sollten behoben werden, bevor die vollständige Konformität erreicht wird.

3. Schwerwiegend: Benutzer mit Behinderungen werden bei der Interaktion mit der Site mit erheblichen Barrieren konfrontiert, was zu Frustration und Schwierigkeiten beim Zugriff auf zugehörige Inhalte führen kann. Um rechtliche Schritte zu vermeiden, sollte der Sanierung höchste Priorität eingeräumt werden.

4. Kritisch: Benutzern mit Behinderungen wird der Zugriff auf eine Funktion der Webseite bzw. die Interaktion mit dieser Funktion vollständig blockiert, wodurch der Inhalt unzugänglich wird und Ihr Unternehmen einem hohen Risiko von Klagen ausgesetzt ist. Die Behebung kritischer Probleme sollte höchste Priorität haben.

Manueller Modus

Standardmäßig analysiert axe Developer Hub jede Ihrer Webseiten automatisch und analysiert die Seiten erneut, wenn es einen neuen [Seitenstatus] erkennt(#page-state). Sie können dieses automatische Verhalten deaktivieren, indem Sie die Eigenschaft autoAnalyze des Konfigurationsobjekts axe auf false setzen. Sie können das automatische Analyseverhalten auch mit der Methode stop überschreiben. In beiden Fällen wird Watcher dadurch in den manuellen Modus versetzt. Im manuellen Modus werden Seiten nur analysiert, wenn Sie die Methode analyze aufrufen.

Modifizierte Testsuite

Eine angepasste Testsuite ist eine Testsuite, die Sie beim Erstellen eines neuen Projekts gemäß den Anweisungen des axe Developer Hub angepasst haben. Durch die Anpassung Ihrer Testsuite können Sie Ihrer vorhandenen Testsuite Barrierefreiheitstests hinzufügen, wobei Sie an der Testsuite selbst nur minimale Änderungen vornehmen müssen.

Seitenstatus

Der Seitenzustand einer Webseite bezieht sich auf den Zustand ihres Dokumentobjektmodells (DOM) zu einem bestimmten Zeitpunkt. Seitenzustände sind hilfreich für komplexe Websites mit Anmeldebildschirmen oder dynamischen Benutzeroberflächen wie Single-Page-Anwendungen (SPAs). Beispiele für den DOM-Zustand sind:

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

Das Paket @axe-core/watcher scannt Webseiten erneut, wenn es Änderungen am DOM erkennt, und speichert jedes Mal einen neuen Seitenstatus.

Projekt

Ein Projekt im axe Developer Hub enthält Ergebnisse zur Barrierefreiheit, Informationen zum Testlauf und Git-Daten (Branches und Commits). Die Verknüpfung dieser Informationen mit dem Projekt erfolgt über den API-Schlüssel des Projekts. Sie erstellen und benennen ein neues Projekt im axe Developer Hub. Dadurch wird ein API-Schlüssel erstellt, der bei Ihren Tests zur Identifizierung des Projekts verwendet werden kann.

Sitzungs-ID

Die Sitzungs-ID wird automatisch als UUID generiert und identifiziert die Anmeldung eines Benutzers auf einem bestimmten Computer. Das Ändern der Sitzungs-ID ist für die meisten Benutzer normalerweise nicht erforderlich. Wenn Sie jedoch zwischen verschiedenen Testläufen unterscheiden müssen, können Sie unterschiedliche Sitzungs-IDs verwenden. Sie sollten eine global eindeutige ID wie eine UUID verwenden, um mögliche Kollisionen der Sitzungs-IDs in derselben Organisation zu vermeiden.

SHA

Wenn Sie mit Git ein Commit erstellen, wird eine ID erstellt, um das Commit eindeutig zu identifizieren. Die eindeutige ID wird SHA genannt (benannt nach den Secure Hash Algorithms, einer Gruppe kryptografischer Hash-Funktionen).

Tag

Ein Tag gruppiert Regeln, die zu einer bestimmten Barrierefreiheitsrichtlinie wie WCAG gehören. Weitere Informationen zu den Regeln und den Tags, zu denen diese Regeln gehören, finden Sie unter [axe-core Regelbeschreibungen].(https://github.com/dequelabs/axe-core/blob/develop/doc/rule-descriptions.md)

WCAG

WCAG oder Web Content Accessibility Guidelines 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 für die Erstellung barrierefreier Websites und digitaler Inhalte, die von Menschen mit den unterschiedlichsten Behinderungen genutzt werden können.

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

WCAG 1.0 war die erste Version dieser Richtlinien und wurde im Jahr 1999 veröffentlicht. WCAG 2.0 wurde im Jahr 2008 veröffentlicht und bot umfassendere Richtlinien, um Webinhalte für Menschen mit einer größeren Bandbreite von Behinderungen zugänglich zu machen.

WCAG 2.1 wurde im Jahr 2018 veröffentlicht. Es baut auf den vorherigen Versionen auf und enthält neue Erfolgskriterien zur Behebung von Zugänglichkeitsproblemen, die seit der Veröffentlichung von WCAG 2.0 aufgetreten sind. WCAG 2.1 enthält außerdem weitere Leitlinien zur Barrierefreiheit für Mobilgeräte, zur Barrierefreiheit für Sehbehinderte sowie zu kognitiven und Lernbehinderungen.

WCAG 2.2, die neueste Version dieser Richtlinien, wurde 2023 veröffentlicht und bietet neun neue Erfolgskriterien gegenüber WCAG 2.1. Es bietet verbesserte Anleitungen, um auf die Bedürfnisse von Benutzern mit kognitiven oder Lernbehinderungen, Benutzern mit Sehschwäche und Benutzern mit Behinderungen auf Mobilgeräten einzugehen. Es ist abwärtskompatibel mit WCAG 2.1.

Einbettung

Unter Einpacken versteht man die Änderung einer Browser-Automatisierungsplattform (wie etwa Cypress), um bei jedem Aufruf einer Funktion der Browser-Automatisierungsplattform einen Code zum Testen der Barrierefreiheit (im Paket @axe-core/watcher) aufzurufen. Durch Wrapping können Sie Barrierefreiheitstests mit minimalen Änderungen an Ihrem Code in Ihre vorhandenen Test-Suiten integrieren.