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 terugleiden naar specifieke codewijzigingen.
• Een Gitless-project organiseert resultaten als een reeks testruns geordend op tijdstempel, zonder enige Git-data.
• 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 woordenlijstitems 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 volledige 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 handicap worden volledig geblokkeerd bij het openen of gebruiken van een functie.
• Ernstig: Gebruikers met een handicap ondervinden significante hindernissen bij het gebruik van de site.
• Matig: Er zijn enkele hindernissen, maar de basisinhoud is nog steeds toegankelijk.
• Kleiner: Minder ernstige problemen die nog steeds oplossing vereisen 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 mergen). 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 beeld.

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 in individuele commits binnen een branch is veranderd, 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 je de GitHub Action gebruikt, kan deze automatisch een reactie op de PR plaatsen met een samenvatting en een link naar de volledige resultaten.

Om te zien 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?

Klik in de Branches-weergave op Commits bekijken op een branch om de individuele gescande commits te zien. In tegenstelling tot de cross-branch-vergelijkingen in de Branches-weergave, gebruikt de Commits-weergave 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 zich verhoudt tot 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 in individuele commits binnen die branch is veranderd, 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. Merge de standaardbranch in je featurebranch (bijvoorbeeld, git merge main) voordat je je 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 je 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 je pipeline te laten falen wanneer er problemen worden gedetecteerd.
• Je kunt fijnmazig bepalen wat een fout vormt door de a11y-drempel te 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 je in staat Axe Developer Hub te ondervragen voor resultaten nadat je test suite is uitgevoerd.
• 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:

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

Zie Resultaten Programmatisch Verkrijgen voor meer opties.