Veelgestelde Vragen

Concepten

Wat is het verschil tussen een Git-project en een Gitless-project?

Developer Hub organiseert je resultaten anders, afhankelijk van of je tests Git gebruiken:

• Een Git-project koppelt toegankelijkheidsresultaten aan branches en commits, waardoor je problemen kunt terugvoeren naar specifieke codewijzigingen.
• Een Gitless-project organiseert resultaten als een reeks testruns gerangschikt op tijdstempel, zonder enige Git-gegevens.
• Git-gegevens zijn beschikbaar bij gebruik van Axe Watcher, de Axe CLI, of de Axe DevTools voor Web APIs (die resultaten via de CLI uploaden). Mobiele projecten zijn altijd Gitless.

Zie Begrijp Je Resultaten en de verklarende woordenlijst voor Git en Gitless voor meer details.

Wat is de a11y-drempel en hoe configureer ik deze?

De a11y-drempel weerspiegelt de tolerantie van je organisatie voor toegankelijkheidsproblemen en bepaalt wat wordt beschouwd als een mislukking in je CI/CD-pipeline:

• Deze wordt berekend op basis van twee criteria: of alle problemen of alleen nieuwe problemen worden meegeteld, en welke impactniveaus worden opgenomen (Kritiek is altijd opgenomen).
• Alleen projectbeheerders kunnen de drempel configureren.

Zie Wijzig de A11y-drempel voor alle details.

Wat betekenen de impactniveaus (Kritiek, Ernstig, Matig, Kleiner)?

Elke toegankelijkheidsschending krijgt een van vier impactniveaus toegewezen, van meest tot minst ernstig:

• Kritiek: Gebruikers met een beperking worden volledig geblokkeerd in het openen of gebruiken van een functie.
• Ernstig: Gebruikers met een beperking ondervinden aanzienlijke obstakels bij het gebruik van de site.
• Matig: Er zijn enkele obstakels, maar de basisinhoud is nog steeds toegankelijk.
• Kleiner: Minder ernstige problemen die nog steeds moeten worden opgelost voor volledige naleving.

Zie de Verklarende Woordenlijst voor gedetailleerde definities.

Vergelijkingen

Developer Hub biedt twee soorten vergelijkingen voor Git-projecten. Kruis-branch vergelijkingen verschijnen in de Branches-weergave, waar elke branch wordt vergeleken met de laatste pipeline-run op de standaardbranch (dit toont wat er zou veranderen als je nu zou samenvoegen). Binnen-branch vergelijkingen verschijnen in de Commits-weergave, waar elke commit wordt vergeleken met de vorige gescande commit op dezelfde branch (dit vertelt je wat een specifieke commit heeft geïntroduceerd of opgelost). Zie Begrijp Je Resultaten voor het volledige plaatje.

Hoe bepaal ik wat er verandert van release tot release?

De Branches-weergave in een Git-project laat je toegankelijkheidsveranderingen bijhouden over releases via een kruis-branch vergelijking:

• De laatste gescande commit van elke branch wordt vergeleken met de laatste pipeline-run op je standaardbranch.
• De vergelijking toont het totale aantal problemen, nieuwe problemen die zijn geïntroduceerd, opgeloste problemen, en eventuele veranderingen in het aantal gescande paginastaten.

Om te zien wat er is veranderd in individuele commits binnen een branch, zie Hoe zie ik wat er van commit tot commit is veranderd binnen een branch?

Hoe kan ik bepalen wat de impact zal zijn van een pull request?

Voer uw test suite uit op de pull request-branch zodat de resultaten verschijnen in Axe Developer Hub:

• In de weergave Branches toont elke niet-standaard branch een vergelijking met de standaardbranch, waarbij nieuwe geïntroduceerde problemen, opgeloste problemen en het totale verschil worden getoond.
• Als u de GitHub Actiongebruikt, kan deze automatisch een opmerking bij de PR plaatsen met een samenvatting en een link naar de volledige resultaten.

Om te bekijken wat elke commit op de branch heeft veranderd, zie Hoe zie ik wat er van commit tot commit is veranderd binnen een branch?

Hoe zie ik wat er van commit tot commit is veranderd binnen een branch?

In de weergave Branches, klik op Commits bekijken op een branch om de individuele gescande commits te zien. In tegenstelling tot de cross-branch vergelijkingen in de weergave Branches, gebruikt de weergave Commits vergelijkingen binnen een branch:

• Elke commit wordt vergeleken met de vorige gescande commit op die branch, waarbij nieuwe problemen, opgeloste problemen en veranderingen in paginastaten worden getoond.
• Alleen commits waarbij de test suite is uitgevoerd, worden getoond.

Om te zien hoe de branch als geheel vergeleken wordt met de standaardbranch, zie Hoe vergelijk ik een branch met de nieuwste CI/CD-run op de standaardbranch?

Hoe vergelijk ik een branch met de nieuwste CI/CD-run op de standaardbranch?

De weergave Branches voert automatisch een cross-branch vergelijking uit voor elke niet-standaard branch met de nieuwste pijplijn run van de standaardbranch:

• Dit vereist dat een projectbeheerder Axe Watcher heeft geconfigureerd om te draaien op de standaardbranch als een pijplijn run.
• De vergelijking toont totale problemen, nieuwe problemen, opgeloste problemen en verschillen in paginastaten.

Om te zien wat er is veranderd in individuele commits binnen die branch, zie Hoe zie ik wat er van commit tot commit is veranderd binnen een branch?

Hoe krijg ik nauwkeurige vergelijkingsresultaten voordat ik een pull request aanmaak?

Voor de meest nauwkeurige cross-branch vergelijking voordat u samengevoegd wordt, houd uw feature branch up-to-date met de standaardbranch:

1. Voeg de standaardbranch samen in uw feature branch (bijvoorbeeld, git merge main) voordat u uw test suite uitvoert.
2. Push de merge commit zodat Axe Developer Hub de bijgewerkte branch kan scannen.
3. De weergave Branches zal vervolgens uw branch vergelijken met de nieuwste pijplijn run op de standaardbranch, waarbij alleen de toegankelijkheidsveranderingen worden getoond die uw branch daadwerkelijk introduceert.

Als uw feature branch achterloopt op de standaardbranch, kan de vergelijking problemen aan het licht brengen die al zijn opgelost in de standaardbranch, maar nog niet zijn samengevoegd in uw feature branch. Door eerst de standaardbranch samen te voegen, worden die valse positieven geëlimineerd en worden verrassingen verminderd wanneer het pull request wordt samengevoegd.

CI/CD

Hoe zorg ik ervoor dat er geen nieuwe toegankelijkheidsproblemen in mijn code worden samengevoegd?

Integreer Axe Developer Hub in uw CI/CD-pijplijn zodat toegankelijkheidscontroles automatisch worden uitgevoerd bij elke commit of pull request:

• Als u GitHub gebruikt, kan de Axe Developer Hub GitHub Action PR's blokkeren die toegankelijkheidsfouten introduceren.
• Voor andere platforms zoals GitLab of Bitbucket, gebruik de REST Service API om resultaten op te vragen en uw pijplijn te laten falen wanneer problemen worden gedetecteerd.
• U kunt fijnmazig instellen wat als een fout geldt door de a11y-drempelte configureren.

Hoe integreer ik Axe Developer Hub met mijn CI/CD-pijplijn als ik geen GitHub gebruik?

U kunt de REST Service API gebruiken om met elk CI/CD-platform te integreren:

• De REST Service API stelt u in staat om resultaten op te vragen bij Axe Developer Hub nadat uw test suite heeft gedraaid.
• De API retourneert het aantal problemen, nieuwe overtredingen, opgeloste overtredingen en een link naar de volledige resultaten in Developer Hub.
• U kunt deze respons gebruiken om uw pipeline te laten slagen of falen in GitLab, Bitbucket, Jenkins, of elk ander platform.

Projectbeheer

Hoe bekijk ik de toegankelijkheidsscans van andere teamleden op een project?

Alle projectleden kunnen alle resultaten binnen een gedeeld project bekijken zodra ze zijn toegevoegd:

• Voeg teamleden toe via de pagina Instellingen voor Leden.
• Bij Git-projecten toont de 'Branches' weergave resultaten gegroepeerd op API-sleutel, zodat u kunt zien wie elke scan heeft uitgevoerd.

Voor details over rollen en permissies, zie Projecten Instellen voor Teamgebruik.

Hoe exporteer ik mijn toegankelijkheidsresultaten?

Developer Hub biedt verschillende manieren om uw gegevens te exporteren:

• Vanuit de overzichtsweergave van het issue, klik op de Exporteren van Issues knop om resultaten te downloaden als CSV of JSON.
• Voor programmatische toegang, gebruik de REST Service API om resultaten voor een specifieke commit en project op te vragen.

Zie Resultaten Programmatisch Verkrijgen voor meer opties.