Häufig gestellte Fragen

Konzepte

Was ist der Unterschied zwischen einem Git-Projekt und einem Gitless-Projekt?

Developer Hub organisiert Ihre Ergebnisse unterschiedlich, je nachdem, ob Ihre Tests Git verwenden:

• Ein Git-Projekt verknüpft Barrierefreiheitsergebnisse mit Branches und Commits, sodass Sie Probleme auf bestimmte Codeänderungen zurückverfolgen können.
• Ein Gitless-Projekt organisiert Ergebnisse als eine Reihe von Testläufen, die nach Zeitstempel geordnet sind, ohne jegliche Git-Daten.
• Git-Daten sind verfügbar, wenn Sie Axe Watcher, die Axe CLI oder die Axe DevTools für Web-APIs verwenden (die die Ergebnisse über die CLI hochladen). Mobile Projekte sind immer Gitless.

Siehe Verstehen Ihrer Ergebnisse und die Glossareinträge für Git und Gitless für weitere Details.

Was ist der a11y-Schwellenwert und wie konfiguriere ich ihn?

Der a11y-Schwellenwert spiegelt die Toleranz Ihrer Organisation gegenüber Barrierefreiheitsproblemen wider und bestimmt, was in Ihrer CI/CD-Pipeline als Fehler zählt:

• Er wird aus zwei Kriterien berechnet: Ob alle Probleme oder nur neue Probleme gezählt werden und welche Auswirkungsstufen einbezogen werden (kritisch wird immer einbezogen).
• Nur Projektadministratoren können den Schwellenwert konfigurieren.

Siehe Ändern des A11y-Schwellenwerts für vollständige Details.

Was bedeuten die Auswirkungsstufen (Kritisch, Ernst, Mäßig, Gering)?

Jede Barrierefreiheitsverletzung wird einer von vier Auswirkungsstufen zugewiesen, von der schwersten bis zur leichtesten:

• Kritisch: Benutzer mit Behinderungen sind vollständig daran gehindert, auf eine Funktion zuzugreifen oder mit ihr zu interagieren.
• Ernst: Benutzer mit Behinderungen stoßen auf erhebliche Barrieren bei der Interaktion mit der Website.
• Mäßig: Einige Barrieren existieren, aber grundlegende Inhalte sind dennoch zugänglich.
• Gering: Weniger schwerwiegende Probleme, die dennoch zur vollständigen Konformität behoben werden müssen.

Siehe das Glossar für detaillierte Definitionen.

Warum werden die gleichen Probleme immer wieder als neu gemeldet?

Um zu entscheiden, ob ein Problem neu ist, vergleicht Developer Hub jedes Ergebnis mit dem vorherigen Lauf anhand der Regel, des Elementselektors und der URL, wie unter Duplikat im Glossar beschrieben. Wenn dasselbe Problem am gleichen Element bei jedem Lauf als neu gemeldet wird, ändert sich eines dieser Kriterien zwischen den Läufen. Es gibt zwei häufige Ursachen.

Die URL ändert sich zwischen den Läufen. Die URL wird vollständig verglichen, sodass eine Sitzungs-ID, ein Zeitstempel, ein Cache-Busting-Parameter oder ein anderer dynamischer Wert in der Abfragezeichenfolge jeden Lauf so erscheinen lässt, als handele es sich um eine andere Seite, und jedes Problem auf einer URL, die zuvor nicht gesehen wurde, als neu gemeldet wird. Es gibt keine Einstellung, die URLs normalisiert, bevor sie verglichen werden, daher besteht die Lösung darin, die URLs, die Ihre Tests aufrufen, deterministisch zu gestalten: Entfernen oder beheben Sie die volatilen Parameter in Ihrer Testumgebung, sodass dieselbe Seite bei jedem Lauf dieselbe URL erzeugt.

Die IDs oder Klassen des Elements ändern sich zwischen den Läufen. Frameworks, die bei jedem Rendern Identifikatoren wie #component-a1b2c3d4 oder .form-field-xyz789 generieren, ändern den Selektor des Elements, sodass es nicht mehr mit dem zuvor aufgezeichneten Element übereinstimmt. Das Festlegen der ancestry-Laufoption auf true behebt dies, da der Vorfahrselektor das Element durch seine Position im DOM-Baum beschreibt und keine IDs oder Klassen enthält:

axe: {
  runOptions: {
    ancestry: true
  }
}

Siehe Verwendung dynamischer Selektoren für die vollständige Erklärung, einschließlich Java-Konfiguration und der Vor- und Nachteile der Aktivierung von ancestry.

Vergleiche

Jeder „Neue-Fälle“ oder „Behobene-Fälle“-Zähler in Developer Hub basiert auf dem Vergleich des aktuellen Scans mit einem Basislinie Scan. Welcher Scan als Basislinie zählt, hängt davon ab, wo Sie schauen:

• Vergleiche über Branches hinweg erscheinen in der Branch-Ansicht. Sie vergleichen den neuesten Scan Ihres Branches mit dem neuesten Pipeline-Lauf auf dem Standard-Branch. Ein Pipeline-Lauf ist ein durch Ihre CI/CD-Pipeline ausgelöster Scan, im Gegensatz zu einem lokalen Lauf vom Rechner eines Entwicklers; Developer Hub markiert diese separat, sodass es immer weiß, welcher Scan des Standard-Branches maßgebend ist. Dies beantwortet die Frage: „Was würde sich ändern, wenn ich jetzt zusammenführe?“
• Vergleiche innerhalb eines Branches erscheinen in der Commits-Ansicht. Sie vergleichen den Scan eines Commits mit dem Scan des vorhergehenden Commits, der Ergebnisse auf demselben Branch hat, was nicht unbedingt der buchstäblich vorhergehende Commit in Ihrer Git-Historie ist: Ein Commit ohne Scan wird übersprungen. Dies beantwortet die Frage: „Was hat dieser spezifische Commit eingeführt oder behoben?“

Der GitHub Action ist keine dritte Vergleichsart. Die Werte, die er einem Pull-Request hinzufügt, sind der Vergleich innerhalb des Branches für den aktuellen Commit, nicht ein Vergleich mit dem Standard-Branch, was eine häufige Quelle der Verwirrung ist, da von einem PR-Check oft erwartet wird, dass er mit dem Branch vergleicht, in den Sie zusammenführen würden.

Siehe Verstehen Ihrer Ergebnisse für das vollständige Bild.

Wie kann ich feststellen, was sich von Version zu Version ändert?

Die Branches-Ansicht in einem Git-Projekt ermöglicht das Verfolgen von Barrierefreiheit-Änderungen über Versionen hinweg, indem ein Vergleich über Branches hinweg verwendet wird:

• Der neueste gescannte Commit eines jeden Branches wird mit dem neuesten Pipeline-Lauf auf Ihrem Standard-Branch verglichen.
• Der Vergleich zeigt die Gesamtzahl der Probleme, neu eingeführte Probleme, gelöste Probleme und alle Änderungen in der Anzahl der gescannten Seitenzustände.

Um zu sehen, was sich in einzelnen Commits innerhalb eines Branches geändert hat, siehe Wie sehe ich, was sich von Commit zu Commit innerhalb eines Branches geändert hat?

Wie kann ich feststellen, welche Auswirkungen ein Pull Request haben wird?

Führen Sie Ihre Testsuite auf dem Pull-Request-Branch aus, damit die Ergebnisse im Axe Developer Hub angezeigt werden:

• In der Ansicht „Branches“ zeigt jeder Nicht-Standard-Branch einen Vergleich mit dem Standard-Branch, der neu eingeführte Probleme, gelöste Probleme und den Gesamtdifferenz aufzeigt.
• Wenn Sie den GitHub Action verwenden, kann dieser automatisch einen Kommentar im PR mit einer Zusammenfassung und einem Link zu den vollständigen Ergebnissen posten.

Um zu erfahren, was jeder Commit auf dem Branch geändert hat, siehe Wie sehe ich, was sich von Commit zu Commit innerhalb eines Branches geändert hat?

Wie sehe ich, was sich von Commit zu Commit innerhalb eines Branches geändert hat?

In der Ansicht „Branches“, klicken Sie auf Commits anzeigen auf einem beliebigen Branch, um dessen einzelne gescannte Commits zu sehen. Im Gegensatz zu den übergreifenden Branch-Vergleichen in der Ansicht „Branches“, verwendet die Ansicht „Commits“ Vergleiche innerhalb des Branches:

• Jeder Commit wird mit dem vorherigen gescannten Commit dieses Branches verglichen, wobei neue Probleme, gelöste Probleme und Änderungen in den Seitenzuständen angezeigt werden.
• Nur Commits, bei denen die Testsuite ausgeführt wurde, werden angezeigt.

Um zu sehen, wie sich der Branch insgesamt im Vergleich zum Standardbranch verhält, siehe Wie vergleiche ich einen Branch mit dem letzten CI/CD-Lauf auf dem Standard-Branch?

Wie vergleiche ich einen Branch mit dem letzten CI/CD-Lauf auf dem Standard-Branch?

Die Branches-Ansicht führt automatisch einen Vergleich jedes Nicht-Standard-Branches mit dem neuesten Pipeline-Lauf des Standard-Branches durch:

• Dies erfordert, dass ein Projektadministrator Axe Watcher so konfiguriert hat, dass er auf dem Standard-Branch als Pipeline-Lauf ausgeführt wird.
• Der Vergleich zeigt die Gesamtprobleme, neue Probleme, gelöste Probleme und Unterschiede in den Seitenzuständen.

Um zu sehen, was sich in einzelnen Commits innerhalb dieses Branches geändert hat, siehe Wie sehe ich, was sich von Commit zu Commit innerhalb eines Branches geändert hat?

Wie erhalte ich genaue Vergleichsergebnisse, bevor ich einen Pull Request erstelle?

Für den genauesten Vergleich zwischen Branches vor dem Zusammenführen halten Sie Ihren Feature-Branch mit dem Standard-Branch aktuell:

1. Mergen Sie den Standardbranch in Ihren Feature-Branch (zum Beispiel, git merge main), bevor Sie Ihren Testlauf ausführen.
2. Pushen Sie den Merge-Commit, damit Axe Developer Hub den aktualisierten Branch scannen kann.
3. Die Branches-Ansicht wird dann Ihren Branch mit dem neuesten Pipeline-Lauf auf dem Standard-Branch vergleichen und nur die Barrierefreiheitsänderungen zeigen, die Ihr Branch tatsächlich einführt.

Wenn Ihr Feature-Branch hinter dem Standard-Branch liegt, könnten im Vergleich Probleme auftauchen, die bereits im Standard-Branch behoben wurden, aber noch nicht in Ihren Feature-Branch integriert sind. Das vorherige Zusammenführen des Standard-Branches eliminiert diese Fehlalarme und verringert Überraschungen, wenn der Pull Request zusammengeführt wird.

Warum sehe ich Probleme, die als neu oder behoben gemeldet werden, wenn ein anderer Satz von Tests ausgeführt wurde?

Ein Vergleich ist nur dann sinnvoll, wenn derselbe Satz von Tests auf beiden Seiten ausgeführt wurde:

• Wenn ein Lauf eine Seite besucht, die der Basislinienlauf nie besucht hat, wird jedes Problem auf dieser Seite als neu gemeldet, weil es nichts gibt, womit es verglichen werden kann.
• Wenn ein Lauf eine Seite überspringt, die die Basislinie abgedeckt hat, erscheinen die Probleme dieser Seite als behoben, obwohl niemand etwas gelöst hat, da sie einfach nicht getestet wurden.
• Zwei Läufe, die tatsächlich unterschiedliche Test-Suiten abdecken, sollten überhaupt nicht verglichen werden; das Ergebnis wird Ihnen nichts Nützliches sagen.

Dies ist nichts, was eine Einstellung beheben kann. Siehe Beste Praktiken für genaue Vergleiche für Informationen, wie Sie Ihre Test-Suite einrichten, damit Vergleiche sinnvoll bleiben.

Beste Praktiken für genaue Vergleiche

• Verwenden Sie ein Projekt pro Test-Satz. Ein Projekt sollte einer Test-Suite entsprechen. Mehrere Suiten auf ein Projekt zu richten bedeutet, dass jeder Lauf mit einer Basislinie verglichen wird, die von einem anderen Satz von Tests produziert wurde, und die Neu- und Behoben-Zähler hören auf, etwas zu bedeuten.
• Führen Sie jedes Mal denselben Satz von Tests aus. Wenn sich die Abdeckung der Suite ändert, ändert sich auch, was der Vergleich Ihnen sagen kann. Wenn die Suite legitim wächst, erwarten Sie einen einmaligen Sprung in neuen Problemen beim Lauf, der die Abdeckung erhöht.
• Richten Sie einen Pipeline-Lauf auf Ihrem Standard-Branch ein. Cross-Branch-Vergleiche messen einen Branch mit dem neuesten Pipeline-Lauf auf dem Standard-Branch. Ohne einen solchen gibt es gar keine Basislinie, und jedes Problem wird als neu gemeldet, was die verwirrendste Version dieses Symptoms ist. Dies einzurichten ist eine Aufgabe des Projektadministrators; siehe Pipeline-Informationen.

CI/CD

Wie stelle ich sicher, dass keine neuen Barrierefreiheitsprobleme in meinen Code gemergt werden?

Integrieren Sie Axe Developer Hub in Ihre CI/CD-Pipeline, damit Barrierefreiheitsprüfungen automatisch bei jedem Commit oder Pull Request durchgeführt werden:

• Wenn Sie GitHub verwenden, kann der Axe Developer Hub GitHub Action PRs blockieren, die Barrierefreiheitseinbußen einführen.
• Für andere Plattformen wie GitLab oder Bitbucket verwenden Sie den REST Service API, um Ergebnisse abzufragen und Ihre Pipeline zu stoppen, wenn Probleme erkannt werden.
• Sie können feineinstellen, was als Fehler gilt, indem Sie den a11y-Schwelle konfigurieren.

Wie integriere ich Axe Developer Hub mit meiner CI/CD-Pipeline, wenn ich GitHub nicht nutze?

Sie können die REST Service API nutzen, um mit jeder CI/CD-Plattform zu integrieren:

• Der REST Service API ermöglicht es Ihnen, Axe Developer Hub nach Ergebnissen abzufragen, nachdem Ihr Testlauf durchgeführt wurde.
• Die API gibt die Anzahl der Probleme, neue Verstöße, gelöste Verstöße und einen Link zu den vollständigen Ergebnissen im Developer Hub zurück.
• Sie können diese Antwort verwenden, um Ihre Pipeline in GitLab, Bitbucket, Jenkins oder einer anderen Plattform zu bestehen oder zu scheitern.

Projektmanagement

Wie kann ich die Accessibility-Scans anderer Teammitglieder in einem Projekt anzeigen?

Alle Projektmitglieder können alle Ergebnisse innerhalb eines gemeinsamen Projekts einsehen, sobald sie hinzugefügt wurden:

• Fügen Sie Teammitglieder über die Mitglieder-Einstellungsseite hinzu.
• Bei Git-Projekten zeigt die Branches-Ansicht Ergebnisse, gruppiert nach API-Schlüssel, damit Sie sehen können, wer welchen Scan durchgeführt hat.

Für Details zu Rollen und Berechtigungen siehe Projekte für die Teamnutzung einrichten.

Wie exportiere ich meine Accessibility-Ergebnisse?

Der Developer Hub bietet mehrere Möglichkeiten, Ihre Daten zu exportieren:

• In der Zusammenfassungsansicht des Problems klicken Sie auf die Schaltfläche Probleme exportieren, um die Ergebnisse als CSV oder JSON herunterzuladen.
• Für den programmatischen Zugriff verwenden Sie den REST Service API, um Ergebnisse für einen bestimmten Commit und ein Projekt abzufragen.

Siehe Ergebnisse programmgesteuert abrufen für weitere Optionen.