Ergebnisse verstehen

This page is not available in the language you requested. You have been redirected to the English version of the page.
Link to this page copied to clipboard

Barrierefreiheitsprobleme mit Axe Developer Hub anzeigen und verwalten

Not for use with personal data

Nachdem Sie den Installationsanweisungen Ihres Toolkit gefolgt sind, werden Ergebnisse generiert, die jedes Mal, wenn Sie Ihre Testsuite ausführen, an den Developer Hub gesendet werden. Im Developer Hub können Sie neue und bestehende Barrierefreiheitsprobleme einsehen und Trends im Laufe der Zeit verfolgen.

Verstehen Ihrer Projektstruktur

Developer Hub organisiert Ihre Barrierefreiheitsdaten unterschiedlich, je nachdem, ob Ihre End-to-End-Tests Git für die Versionskontrolle verwenden:

Bei Verwendung von Git, Sie können verschiedene Zweige Ihres Projekts und einzelne Commits auf diesen Zweigen anzeigen. Die Struktur sieht wie folgt aus:
Projekt → Zweige → Commits → Liste der Probleme → Problemdetails

note

Git-Daten werden automatisch für Axe Watcher-Projekte gesammelt. Git-Informationen entsprechen dem End-to-End-Test, der möglicherweise nicht genau mit dem tatsächlich getesteten Code übereinstimmt, wenn sich der Code in einem vom End-to-End-Test separaten Repository befindet.

Verwenden Sie unsere APIs, um die Sammlung von Git-Daten für Ihr Watcher-Projekt zu deaktivieren:

Wenn Sie Git nicht mit Ihrem Webprojekt verwenden oder wenn Sie ein mobiles Projekt ansehen, Sie sehen einzelne Testläufe und können zu den in jedem Lauf gefundenen Problemen navigieren. Die Struktur sieht wie folgt aus:
Projekt → Testläufe → Liste der Probleme → Problemdetails

Arbeiten mit Ihren Ergebnissen

Wenn Sie ein Projekt öffnen, sehen Sie entweder eine Liste der Zweige (Git-Projekte) oder Testruns (Gitlose Projekte).

Ihre Ergebnisse auf einen Blick

Sie werden die folgenden Informationen aus Ihrer Barrierefreiheitsprüfung erhalten:

  • Für Git-Projekte: Zweigname, zuletzt commitierte SHA und Commit-Nachricht für den aktuell laufenden End-to-End-Test
  • Für Gitlose Projekte: Zeitstempel des Testlaufs
  • Anzahl der Probleme, die den Barrierefreiheits-Threshold überschreiten
  • Paket- und Versionsinformationen für das von Ihnen verwendete Barrierefreiheitstoolkit
  • Vergleichsübersicht mit Gesamtanzahl der Probleme und Anzahl der Scans
  • Eine Zählung neuer Probleme, die eingeführt wurden, und gelöster Probleme (nur Webprojekte)
  • Barrierefreiheits-Score (nur für mobile Projekte): Ein Prozentsatz (0–100 %), der zeigt, wie zugänglich die Sitzungs-Scans waren, im Folgenden detailliert in Barrierefreiheits-Score (Nur Mobile Projekte)
  • „Commits anzeigen“-Button (nur Git-Projekte), um in einzelne Commits einzutauchen
  • „Probleme anzeigen“-Button, um die vollständige Problemliste zu sehen

Barrierefreiheits-Score (Nur Mobile Projekte)

Der Barrierefreiheits-Score ist ein Prozentsatz (0–100 %), der auf den Berichtsseiten mobiler Sitzungen angezeigt wird. Ein höherer Score bedeutet weniger schwerwiegende Barrierefreiheitsprobleme in der gesamten Sitzung.

Der Score wird in zwei Schritten berechnet:

  1. Jeder Scan wird bewertet basierend auf dessen schwerwiegendstem Barrierefreiheitsproblem:

    • 100 % — nur geringfügige Probleme oder gar keine Probleme
    • 80 % — mindestens ein moderates Problem; keine schwerwiegenden oder kritischen Probleme
    • 40 % — mindestens ein schwerwiegendes Problem; keine kritischen Probleme
    • 0 % — mindestens ein kritisches Problem
  2. Der Sitzungs-Score ist der Durchschnitt aller Scan-Ergebnisse.

Beispielsweise würde eine Sitzung mit drei Scans, einer mit nur geringfügigen Problemen, einer mit einem schwerwiegenden Problem und einer mit einem kritischen Problem, einen Score von (100 + 40 + 0) / 3 ≈ 47 % erzielen.

Sitzungen ohne Scans zeigen einen leeren Zustand anstatt 0 %.

Für die vollständige Formelspezifikation siehe Berechnen eines Scores in der Axe DevTools Mobile-Dokumentation.

note

Der Barrierefreiheits-Score erscheint nur auf mobilen Sitzungseiten.

Sitzungen umbenennen

Standardmäßig werden Sitzungen anhand ihrer Git-Zweig- und Commit-Informationen (Git-Projekte) oder ihres Zeitstempels (Gitlose Projekte) identifiziert. Sie können jeder Sitzung einen benutzerdefinierten Anzeigenamen geben, um bestimmte Scan-Läufe leichter zu identifizieren.

Benutzerdefinierte Namen erscheinen überall im Developer Hub, wo eine Sitzung referenziert wird: Seitenüberschriften, Paneltitel, Brotkrümel und Vergleichslabels. Der ursprüngliche Git- oder Zeitstempel-Identifier bleibt im Metadatenbereich auf der Problemseite sichtbar.

Um eine Sitzung umzubenennen, öffnen Sie deren Problemseite und klicken Sie im Seitenkopf auf die Schaltfläche Bearbeiten. Projektadministratoren, Mitwirkende und Organisationsadministratoren können jede Sitzung im Projekt umbenennen.

Pipeline-Informationen

Für Teams, deren Tests Git-Daten mit Axe Watcher verwenden, können alle Läufe mit den CI/CD-Läufen im Standardzweig verglichen werden, um sicherzustellen, dass neu zusammengeführter Code keine zusätzlichen Barrierefreiheitsprobleme einführt. Um den Vergleich einzurichten, muss ein Projektadministrator Watcher auf dem Standardzweig des Repositories ausführen - dies ist normalerweise der main (oder master) Zweig. Diese Instanz des Toolkits muss als Pipeline-Lauf eingerichtet werden.

Sobald Scandaten aus dem festgelegten Pipeline-Lauf auf dem Standardzweig eintreffen, werden die Ergebnisse oben auf der Seite angezeigt. Benutzer können verschiedene Ergebnissätze nach API-Schlüssel anzeigen und sehen, wie sie im Vergleich zu dem Pipeline-Lauf auf dem Standardzweig abschneiden.

Erfahren Sie mehr über die Einrichtung von Pipeline-Läufen mit Axe Watcher in Continuous-Integration-Umgebungen

Vergleiche verstehen

Die Vergleichsinformationen, die für Webprojekte bereitgestellt werden, helfen Ihnen zu verstehen, was sich geändert hat:

  • Für Git-Projekte:
    • Auf der Seite, die alle Zweige Ihres Projekts anzeigt, können Sie sehen, wie sich der letzte Commit auf jedem Zweig im Vergleich zum letzten Pipeline-Lauf im Standardzweig verhält.
    • Wenn Sie einen einzelnen Zweig zur Ansicht auswählen, können Sie sehen, wie sich jeder einzelne Commit auf diesem Zweig im Vergleich zum vorhergehenden Commit verhält.
  • Für Gitless-Projekte: Jeder Testlauf wird mit dem vorhergehenden Lauf verglichen.

Wenn Sie keine Vergleichsdaten sehen, ist wahrscheinlich kein vorheriger Scan verfügbar, mit dem verglichen werden könnte, oder ein Pipeline-Scan wurde im Standardbranch noch nicht ausgeführt.

Erfahren Sie mehr über die Verwendung von Vergleichen zur Verfolgung von Trends

Mehr über Barrierefreiheitsprobleme erfahren

Nach dem Klicken auf Probleme anzeigen von einem Zweig, Commit oder Testlauf sehen Sie eine Übersichtsseite, die Barrierefreiheitsverletzungen nach Regel und Auswirkungensebene auflistet und gruppiert.

Vergleichstabelle (nur für Webprojekte)

Webprojekte zeigen oben eine Vergleichstabelle mit folgenden Informationen:

  • Gesamtzahl der Probleme in aktuellen und Basisscans
  • Neue eingeführte Probleme
  • Bereits bestehende Probleme
  • Behobene Probleme
  • Alle diese sind nach Auswirkungsgrad gruppiert (Kritisch, Ernst, Mittel, Gering)

Hinweis: Mobile Projekte enthalten diese Vergleichstabelle nicht.

Regelliste

Unterhalb des Vergleichsabschnitts (oder oben bei mobilen Projekten) sehen Sie alle verletzten Barrierefreiheitsregeln gruppiert nach:

  • Regelname (den Sie auswählen können, um einzelne Probleme anzuzeigen)
  • Auswirkungsgrad
  • Anzahl der für diese Regel gefundenen Verstöße

Filtern und Exportieren

Mit Webprojekten können Sie die Filtersteuerung verwenden, um sich auf bestimmte Probleme zu konzentrieren:

  • Filtern nach Auswirkungsgrad (Kritisch, Ernst, Mittel, Gering)
  • Nur neue Probleme anzeigen
  • Spezifische Seitenelemente auswählen

Mit Mobilen Projekten können Sie den Filter verwenden, um einen oder mehrere Bildschirme in der Liste auszuwählen und sich auf bestimmte Ergebnisse zu konzentrieren.

Exportieren Sie Ihre Ergebnisse:

  • Web
    • Exportieren Sie JSON, um detaillierte Ergebnisse in menschenlesbarem Format leicht zu teilen
    • Exportieren Sie CSV für Tabellenkalkulationen und Berichte
  • Mobil
    • Exportieren Sie im Axe-Universal-JSON-Format für die Integration mit anderen Tools

Exporte richten sich nach Ihren aktuellen Filtern.

Einzelne Problem-Seite

Klicken Sie auf einen beliebigen Regelname in der Problemliste, um detaillierte Informationen zu jedem Verstoß zu sehen.

Probleme im Code finden

Webprojekte bieten:

  • Element-Quellcode (HTML-Snippet)
  • CSS-Selektor zur Lokalisierung des Elements
  • XPath-Ausdruck als alternativer Locator
  • Alle mit Kopierschaltflächen zur einfachen Nutzung in Ihren Entwicklungstools

Mobile-Projekte bieten:

  • Screenshot mit hervorgehobenem Problem
  • Detailansicht: Bietet Kontext für das problematische Element
  • Inspektionshierarchieansicht: Zeigt den Hierarchiebaum, um den genauen Standort zu ermitteln und detaillierte Eigenschaften des Elements zu sehen

Leitfaden zur Behebung

Jedes Problem umfasst:

  • Regelbeschreibung, die das Zugänglichkeitsproblem erklärt
  • Links zu Deque University oder Mobilen Regel-Seiten für umfassende Anleitungen und Codebeispiele
  • Auswirkungsgrad und Barrierefreiheits-Tags (WCAG-Kriterien, Best Practices)
  • Navigation zur Durchschau aller Instanzen dieses Verstoßes (z.B. „1 von 5“)

Probleme teilen

Klicken Sie oben auf der Seite auf Problemlink kopieren, um mit Ihrem Team zu teilen oder es Ihrem Problemverfolgungssystem hinzuzufügen.

Freigabeberechtigungen: Problemlink respektieren die Freigabeeinstellungen Ihrer Organisation. Teammitglieder benötigen entsprechende Berechtigungen, um Probleme anzeigen zu können. Administratoren können die Freigabeeinstellungen in: