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.

Vergleiche

Developer Hub bietet zwei Arten von Vergleichen für Git-Projekte. Vergleiche über Branches hinweg erscheinen in der Ansicht „Branches“, wo jeder Branch mit dem neuesten Pipeline-Lauf auf dem Standardbranch verglichen wird (dies zeigt, was sich ändern würde, wenn Sie jetzt mergen). Vergleiche innerhalb eines Branches erscheinen in der Ansicht „Commits“, wo jeder Commit mit dem vorher gescannten Commit auf demselben Branch verglichen wird (dies zeigt, was ein spezifischer Commit eingeführt oder behoben hat). 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.

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.