Dynamische Selectors gebruiken

Bij het testen van pagina's die dynamische elementen-ID's of klassenamen genereren bij elke paginaweergave, kan Axe Watcher moeite hebben om te volgen of toegankelijkheidsproblemen duplicaten zijn in verschillende testuitvoeringen. Dit artikel legt uit hoe u Watcher kunt configureren om deze scenario's correct af te handelen. Een dynamische URL veroorzaakt hetzelfde symptoom om een andere reden en heeft een andere oplossing nodig, behandeld in de Dynamische URL's hieronder.

Het probleem met dynamische selectors

Standaard gebruikt Axe Watcher CSS-selectors die element-ID's en klassen bevatten om te bepalen waar toegankelijkheidsproblemen zich voordoen. Bijvoorbeeld, een probleem kan worden gemeld op:

iframe#main-iframe

Deze aanpak werkt goed wanneer de ID's en klassen van uw pagina consistent blijven tussen paginaladingen. Echter, veel moderne webapplicaties genereren dynamische identificatoren die bij elke paginarender wijzigen, zoals:

• #component-a1b2c3d4
• .form-field-xyz789

Axe Watcher stuurt ook een XPath voor elk element, en Axe Developer Hub beschouwt een overeenkomst op een van beide selectors als hetzelfde element. Omdat een XPath nooit klassenamen bevat, wordt een pagina waarvan alleen de klassenamen dynamisch zijn vaak correct gevolgd zonder verdere configuratie. Een XPath bevat echter wel het ID van een element wanneer dat ID uniek is op de pagina, waardoor een pad wordt geproduceerd zoals //div[@id='component-a1b2c3d4']. Een dynamisch ID verandert daarom zowel de CSS-selector als de XPath samen, waardoor er niets stabiel is om op te matchen.

Wanneer op deze manier identificaties veranderen tussen testuitvoeringen, kan Axe Watcher niet bepalen of een probleem een duplicaat is van een eerder gedetecteerd probleem of een nieuwe gebeurtenis. Dit kan resulteren in:

• Hetzelfde probleem dat bij elke testuitvoering als zowel „nieuw“ als „opgelost“ wordt gerapporteerd
• Ongenaue bewaking van uw voortgang in toegankelijkheid na verloop van tijd
• Moeilijkheden bij het identificeren van welke problemen daadwerkelijk zijn opgelost

De oplossing: Ancestry Tracking inschakelen

Om met dynamische selectors om te gaan, stelt u de ancestry optie in op true in uw runOptions configuratie. Wanneer ingeschakeld, gebruikt Axe Watcher de positie van het element binnen de DOM-boom in plaats van te vertrouwen op ID's en klassen om elementen te lokaliseren tussen testuitvoeringen.

Met ancestry ingeschakeld, zag een selector er eerder zo uit:

iframe#main-iframe

Zal in plaats daarvan het volledige pad vanaf het rootelement bevatten:

html > body > div:nth-child(20) > div:nth-child(1) > div > div > ul > li:nth-child(1) > div > span > iframe

Deze positionele selector blijft consistent over paginaladingen heen, zelfs wanneer ID's en klassen veranderen, waardoor Axe Watcher duplicaatproblemen nauwkeurig kan volgen.

Voorbeeldconfiguraties

JavaScript en TypeScript

Voeg de ancestry optie toe aan uw axe-configuratie's runOptions:

const config = {
  axe: {
    apiKey: process.env.ACCESSIBILITY_API_KEY,
    projectId: process.env.PROJECT_ID,
    runOptions: {
      ancestry: true
    }
  }
}

Java

Gebruik de setAncestry() methode op uw AxeRunOptions object:

AxeRunOptions runOptions = new AxeRunOptions()
    .setAncestry(true);

AxeWatcherOptions options = new AxeWatcherOptions()
    .setApiKey(System.getenv("ACCESSIBILITY_API_KEY"))
    .setProjectId(System.getenv("PROJECT_ID"))
    .setRunOptions(runOptions);

AxeWatcher watcher = new AxeWatcher(options);

Wanneer Ancestry Tracking te gebruiken

Schakel ancestry: true in wanneer uw applicatie:

• Frameworks gebruikt die dynamische component-ID's genereren (React, Vue, Angular)
• CSS-in-JS bibliotheken gebruikt die unieke klassennamen genereren
• Formuliervelden of interactieve elementen met automatisch gegenereerde identificatoren heeft
• Inconsistente „nieuw probleem“ en „opgelost probleem“ tellingen vertoont tussen testuitvoeringen voor wat dezelfde problemen lijken te zijn

Afwegingen om in acht te nemen

Hoewel ancestry tracking het probleem van dynamische selectors oplost, zijn er enkele overwegingen:

• Leesbaarheid van selectors: Positionele selectors zijn langer en kunnen moeilijker te lezen zijn bij het bekijken van problemen in de Axe Developer Hub.
• Gevoeligheid voor DOM-structuur: Als de DOM-structuur van uw pagina significant verandert tussen renders (niet alleen de ID's/klassen), kunnen de positionele selectors ook veranderen.
• Debugging: Bij het onderzoeken van een probleem kan het gemakkelijker zijn om een element op te sporen aan de hand van een betekenisvolle ID dan via zijn positie in de DOM-boom.

Voor de meeste applicaties met dynamische identificatoren wegen de voordelen van nauwkeurige probleemtracking zwaarder dan deze nadelen.

Dynamische URL's

Elementselectors zijn slechts een deel van hoe Axe Developer Hub een probleem identificeert. Ook de URL van de pagina wordt volledig vergeleken, inclusief eventuele querystring. Het inschakelen van ancestry heeft geen invloed op deze vergelijking.

Een URL die varieert tussen testuitvoeringen veroorzaakt dus dezelfde symptomen als een dynamische selector, en doet dit nog agressiever: wanneer een URL nog niet eerder is gezien, wordt elk probleem dat erop wordt gevonden als nieuw gerapporteerd, zonder dat de elementselectors überhaupt worden geraadpleegd. Veelvoorkomende oorzaken zijn:

• Session-ID's of authenticatietokens die in de querystring worden gedragen
• Tijdstempels of cache-busting parameters, zoals ?v=1738012800
• Gecodificeerde ID's in het pad, zoals /orders/8f3c1b2a/summary
• Testopstellingen die bij elke uitvoering een nieuw record genereren, en daardoor een nieuwe URL

Er is geen configuratieoptie die URL's normaliseert voordat ze worden vergeleken, dus dit moet in uw testsuite worden opgelost: navigeer naar deterministische URL's, zodat dezelfde pagina elke keer dezelfde URL genereert. In de praktijk betekent dit meestal dat vaste testgegevens worden gezaaid in plaats van nieuwe records per uitvoering te genereren, en dat vluchtige queryparameters worden verwijderd of vastgezet voordat de pagina wordt gescand.

Als een URL echt niet kan worden gestabiliseerd, kunt u deze volledig uit uw resultaten houden met excludeUrlPatterns, hoewel dit betekent dat de pagina helemaal niet wordt gescand in plaats van correct te worden gevolgd. Zie URL's uitsluiten van analyse voor details.

Zie ook

• API-referentie voor JavaScript en TypeScript Volledige documentatie voor runOptions en andere configuratieopties
• AxeRunOptions Klasse Java API-referentie voor runtime-opties
• Woordenlijst: Duplicaat Inzicht in hoe Axe Developer Hub duplicaatproblemen identificeert