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, können Sie verschiedene Zweige Ihres Projekts und einzelne Commits auf diesen Zweigen einsehen. Die Struktur ist wie folgt:
Projekt → Zweige → Commits → Problemliste → 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 separaten Repository vom End-to-End-Test 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, sehen Sie einzelne Testruns und können zu den in jedem Run gefundenen Problemen navigieren. Die Struktur ist wie folgt:
Projekt → Testruns → Problemliste → 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: Name des Zweigs, neueste Commit-SHA und Commit-Nachricht für den laufenden End-to-End-Test
  • Für Gitlose Projekte: Zeitstempel des Testruns
  • Anzahl der Probleme, die den Barrierefreiheits-Threshold
  • 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 mobile Projekte): Ein Prozentsatz (0–100 %), der zeigt, wie zugänglich die Scans der Sitzung waren, detailliert unten 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 seinem schwerwiegendsten 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-Scores.

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 Formularspezifikation 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 auf dem Standardzweig verglichen werden, um sicherzustellen, dass neu zusammengeführter Code keine zusätzlichen Barrierefreiheitsprobleme einführt. Um den Vergleich einzurichten, muss ein Projektadministrator Watcher so einstellen, dass es auf dem Standardzweig des Repositories läuft - dies ist normalerweise der main (oder master) Zweig. Diese Instanz des Toolkit 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 das Einrichten 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 der neueste Commit auf jedem Zweig mit dem neuesten Pipeline-Lauf im Standardbranch verglichen werden.
    • Wenn Sie einen einzelnen Branch auswählen, um ihn anzusehen, können Sie sehen, wie jedes einzelne Commit in diesem Branch im Vergleich zu dem vorhergehenden Commit abschneidet.
  • Für Gitless-Projekte: Jeder Testlauf wird mit dem vorherigen 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 Branch, Commit oder Testlauf aus, sehen Sie eine Übersichtsseite, die Barrierefreiheitsverletzungen nach Regel und Auswirkungsgrad gruppiert auflistet.

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 Webprojektenkönnen Sie die Filtersteuerungen nutzen, um sich auf bestimmte Probleme zu konzentrieren:

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

Mit Mobilen Projektenkönnen Sie den Filter verwenden, um ein 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 auf Problemlink kopieren oben auf der Seite, um ihn mit Ihrem Team zu teilen oder zu Ihrem Problemerfassungssystem hinzuzufügen.

Freigabeberechtigungen: Problemlinks berücksichtigen die Freigabeeinstellungen Ihrer Organisation. Teammitglieder benötigen die entsprechenden Berechtigungen, um Probleme anzuzeigen. Administratoren können Freigabeeinstellungen konfigurieren in: