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.

Waarom worden dezelfde problemen steeds als nieuw gemeld?

Om te bepalen of een probleem nieuw is, vergelijkt Developer Hub elk resultaat met de vorige uitvoering op basis van regel, elementselector en URL, zoals beschreven onder Duplicaat in de woordenlijst. Als hetzelfde probleem bij hetzelfde element bij elke uitvoering als nieuw wordt gemeld, verandert één van deze drie tussen de uitvoeringen. Er zijn twee veelvoorkomende oorzaken.

De URL verandert tussen de uitvoeringen. De URL wordt volledig vergeleken, dus een sessie-ID, een tijdstempel, een cache-busting parameter of een andere dynamische waarde in de querystring doet elke uitvoering eruitzien als een andere pagina, en elk probleem op een nog niet eerder geziene URL wordt als nieuw gemeld. Er is geen instelling die URL's normaliseert voordat ze worden vergeleken, dus de oplossing is om de URL's die je tests bezoeken deterministisch te maken: verwijder of corrigeer de vluchtige parameters in je testopstelling zodat dezelfde pagina bij elke uitvoering dezelfde URL oplevert.

De ID's of klassen van het element veranderen tussen de uitvoeringen. Frameworks die op elke render identificatoren zoals #component-a1b2c3d4 of .form-field-xyz789 genereren, wijzigen de selector van het element, zodat het niet langer overeenkomt met het element dat eerder is vastgelegd. Het instellen van de ancestry uitvoeringsoptie op true lost dit op, omdat de voorouderselector het element beschrijft door zijn positie in de DOM-boom en geen ID's of klassen bevat:

axe: {
  runOptions: {
    ancestry: true
  }
}

Zie Dynamische Selectors gebruiken voor de volledige uitleg, inclusief Java-configuratie en de afwegingen van het inschakelen van ancestry.

Vergelijkingen

Elke telling van "nieuw probleem" of "opgelost probleem" in Developer Hub komt voort uit het vergelijken van de huidige scan met een baseline scan. Welke scan als baseline geldt, hangt af van waar je kijkt:

• Kruis-branch vergelijkingen verschijnen in de Branches-weergave. Ze vergelijken de nieuwste scan van jouw branch met de nieuwste pipeline-uitvoering op de standaardbranch. Een pipeline-uitvoering is een scan die wordt geactiveerd door je CI/CD-pipeline, in tegenstelling tot een lokale uitvoering vanaf de machine van een ontwikkelaar; Developer Hub markeert deze apart zodat het altijd weet welke scan van de standaardbranch gezaghebbend is. Dit beantwoordt de vraag "wat zou er veranderen als ik nu zou samenvoegen?"
• Binnen-branch vergelijkingen verschijnen in de Commits-weergave. Ze vergelijken de scan van een commit met de scan van de vorige commit die resultaten heeft op dezelfde branch, wat niet noodzakelijkerwijs de letterlijke vorige commit in je Git-geschiedenis is: een commit zonder scan wordt overgeslagen. Dit beantwoordt de vraag "wat introduceerde of loste deze specifieke commit op?"

De GitHub Action is geen derde vergelijkingstype. De tellingen die het aan een pull request doorgeeft, zijn de interne vergelijking binnen de branch voor de huidige commit, niet een vergelijking met de standaardbranch, wat vaak verwarring veroorzaakt omdat van een PR-controle vaak wordt verwacht dat deze vergelijkt met de branch waar je naar wilt samenvoegen.

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 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.

Waarom zie ik problemen als nieuw of opgelost gemeld wanneer een andere reeks tests werd uitgevoerd?

Een vergelijking is alleen zinvol wanneer dezelfde reeks tests aan beide zijden is uitgevoerd:

• Als een uitvoering een pagina bezoekt die de baseline-uitvoering nooit heeft bezocht, wordt elk probleem op die pagina als nieuw gemeld, omdat er niets is om het tegen te vergelijken.
• Als een uitvoering een pagina overslaat die de baseline heeft behandeld, worden de problemen van die pagina als opgelost weergegeven, hoewel er niets is gerepareerd, omdat ze simpelweg niet zijn getest.
• Twee uitvoeringen die echt verschillende testsuites dekken, moeten helemaal niet worden vergeleken; het resultaat zal je niets nuttigs vertellen.

Dit is niet iets dat een instelling kan oplossen. Zie Beste Praktijken voor Nauwkeurige Vergelijkingen voor hoe je je testsuite zo kunt instellen dat vergelijkingen zinvol blijven.

Beste Praktijken voor Nauwkeurige Vergelijkingen

• Gebruik één project per reeks tests. Een project moet overeenkomen met één testsuite. Door meerdere suites op één project te richten, vergelijkt elke uitvoering met een baseline die door een andere reeks tests is geproduceerd, waardoor de tellingen van nieuwe en opgeloste problemen geen betekenis meer hebben.
• Voer elke keer dezelfde reeks tests uit. Het veranderen van wat de suite dekt, verandert wat de vergelijking je kan vertellen. Wanneer de suite legitiem groeit, verwacht dan een eenmalige sprong in nieuwe problemen bij de uitvoering die de dekking toevoegt.
• Stel een pipeline-uitvoering in op je standaardbranch. Cross-branch vergelijkingen meten een branch tegen de nieuwste pipeline-uitvoering op de standaardbranch. Zonder die bestaat er geen baseline, en wordt elk probleem als nieuw gemeld, wat de meest verwarrende versie van dit symptoom is. Het instellen hiervan is een taak voor de projectbeheerder; zie Pipeline-informatie.

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.