Het Juiste Axe DevTools Linter Configuratie Kiezen

This page is not available in the language you requested. You have been redirected to the English version of the page.

Link to this page copied to clipboard

Een gids voor het selecteren van het inzetmodel, integraties en configuratie die passen bij de workflow van uw team

Not for use with personal data

Axe DevTools Linter kan op veel manieren worden gebruikt, en de juiste combinatie hangt af van hoe uw team code schrijft, beoordeelt en levert. Deze gids leidt u door de belangrijkste beslissingen zodat u een configuratie kunt kiezen die bij uw omstandigheden past. De meeste teams combineren meerdere van deze opties in plaats van er slechts één te kiezen.

De beslissingen vallen in vier gebieden:

Waar de analyse plaatsvindt (of bestanden lokaal of op een server worden gecontroleerd, en welk inzetmodel die server host)
Waar linting in uw workflow plaatsvindt (IDE, pre-commit hook, CI/CD)
Of u componentbibliotheken moet configureren
Wanneer andere integraties toe te voegen zoals SonarQube

note

Deze gids helpt u beslissen welk opties te gebruiken. Voor stapsgewijze instructies over hoe elke optie instelt, volgt u de links naar de afzonderlijke pagina's. Voor een overzicht op functieniveau van alles wat Axe DevTools Linter biedt, zie Over Axe DevTools Linter.

1. Kies Waar de Analyse Plaatsvindt

Hier zijn twee gerelateerde keuzes: of uw bestanden op uw eigen machine of naar een server worden gestuurd voor analyse, en, als een server betrokken is, welk soort server deze host.

Lokale of Servergebaseerde Linting

Waar uw bestanden worden geanalyseerd, en of hun inhoud uw machine verlaat, hangt af van de integratie. De drie integratiefamilies werken verschillend:

IDE-integraties linten altijd lokaal. De VS Code-extensie en de JetBrains-plugin analyseren bestanden op uw eigen machine met een meegeleverd component, dus de bestandsinhoud verlaat uw computer nooit. Ze vereisen geen API-sleutel of licentiesleutel om te linten.
De Connector kan op beide manieren linten. Standaard stuurt de Connector bestanden naar een Axe DevTools Linter-server, maar zijn --local optie analyseert ze op uw machine, zodat hun inhoud deze nooit verlaat. Deque beveelt lokale linting aan voor de meeste gevallen: het is aanzienlijk sneller en minder gevoelig voor netwerkproblemen, vooral bij het controleren van grote aantallen bestanden. Hoe u ook lintt, de Connector voert authenticatie uit, zoals hieronder beschreven in Connector-authenticatie.
De GitHub Action is altijd servergebaseerd. De GitHub Actie stuurt gewijzigde bestanden naar een Axe DevTools Linter-server voor analyse. Het heeft geen lokale lintingmodus, dus deze optie stuurt de bestandsinhoud altijd naar de server.

Connector Authenticatie

Wanneer u de Connector gebruikt, authenticeert u met een van de twee inloggegevens, of u nu lokaal lintt of tegen een server:

API-sleutel (de --api-key optie): U beheert zelf API-sleutels als onderdeel van uw Axe-account. De Connector neemt contact op met een externe server om de sleutel te valideren en het gebruik te rapporteren (de regels code die worden gecontroleerd). Dit gebeurt zelfs wanneer u lokaal lintt.
Licentiesleutel (de --license-key optie): U vraagt een licentiesleutel aan bij Deque's Helpdesk. Het wordt geverifieerd zonder netwerkactiviteit en volgt het gebruik niet, wat het de juiste keuze maakt voor netwerken zonder verbinding met buiten of omgevingen met strikte uitgaande regels. Het is alleen beschikbaar met lokale linting.

Dit geeft de Connector drie manieren om te functioneren:

Modus	Waar bestanden worden geanalyseerd	Netwerk tijdens linting	Gebruik gevolgd
API-sleutel, servergebaseerd (de standaard)	Linter-server	Ja, bestanden plus authenticatie	Ja
API-sleutel met `--local`	Uw machine	Alleen authenticatie en gebruik; bestandsinhoud blijft lokaal	Ja
Licentiesleutel met `--local`	Uw machine	Geen	Nee

De IDE-integraties hebben geen referentie nodig om te linten. De GitHub-actie authenticatie met een API-sleutel; de installatiehandleiding behandelt de workflow voor zowel SaaS- als on-premisesservers.

Serverimplementatiemodel

Als u linet tegen een server, of authenticeert met een API-sleutel terwijl u lokaal lint, kiest u ook welk type server Axe DevTools Linter host. Dit beïnvloedt de installatie-inspanning, of uw bestanden uw netwerk verlaten en hoe u authenticateert.

Model	Wat het is	Installatie-inspanning	Authenticatie
Deque-gehoste SaaS	Deque draait de lintserver in zijn cloud.	Geen	API-sleutel
On-premises	U draait de lintserver binnen uw eigen infrastructuur. Bron verlaat nooit uw netwerk.	U installeert en onderhoudt de server. Zie Installatie en beveiliging.	Licentiesleutel
Privécloud	Een toegewijde, door Deque gehoste instantie voor uw organisatie.	Beheerd door Deque	API-sleutel, om te authenticeren en gebruik te rapporteren wanneer lokaal linten

Kies SaaS voor de snelste start en geen infrastructuur om te onderhouden. Kies on-premises wanneer beleid vereist dat broncode binnen uw netwerk blijft, of wanneer u volledige controle over de server wilt. Kies privécloud wanneer u een toegewijde door Deque beheerde instantie wilt zonder zelf de server te draaien.

2. Kies Waar Linten Gebeurt in Uw Workflow

Toegankelijkheidsfeedback is het meest nuttig vroeg en vaak. De onderstaande integraties worden toegepast op verschillende punten in de ontwikkelingscyclus, en ze werken goed samen: problemen opsporen terwijl u typt, opnieuw vóór een commit, en nog een keer in de pull-aanvraag.

Integratie	Wanneer het draait	Beste voor
VS Code-extensie / JetBrains-plug-in	Terwijl u typt, in de editor	Realtime feedback voor individuele ontwikkelaars
Git pre-commit hook	Voordat een commit wordt geaccepteerd	Voorkomen dat toegankelijkheidsfouten de repository binnendringen
GitHub-actie	Bij een pull-aanvraag	Team-brede controles die inline commentaar geven op gewijzigde bestanden
Connector	In scripts en CI/CD-pijplijnen	Batch-linting en het bouwen van aangepaste automatisering

Een gebruikelijke, gelaagde aanpak is:

IDE-extensie zodat ontwikkelaars problemen onmiddellijk zien terwijl ze code schrijven.
Pre-commit hook of GitHub-actie als een poort, zodat problemen worden opgevangen voor of tijdens code review.
Connector in CI/CD om controles af te dwingen over de gehele codebase en om andere systemen te voeden.

Je hoeft niet meteen alle drie de lagen te adopteren. Teams beginnen vaak met de IDE-extensie en voegen vervolgens een pull request-check toe zodra ze klaar zijn om standaarden binnen het team af te dwingen.

3. Beslis of u Componentbibliotheken Wilt Configureren

Standaard controleert Axe DevTools Linter standaard HTML-elementen en frameworkmarkeringen. Als uw code gebruikmaakt van aangepaste componenten (bijvoorbeeld een <custom-image> die een <img> weergeeft), kan de linter deze niet controleren op toegankelijkheid totdat u vertelt hoe elk component aan een standaardelement is gekoppeld.

Je zou component-linting moeten configureren als:

Je codebase afhankelijk is van een designsysteem of een aangepaste componentbibliotheek, en
Je wilt dat toegankelijkheidsproblemen binnen die componenten worden gemarkeerd.

Er zijn twee paden:

Vooraf geconfigureerde componentbibliotheken: Als je Cauldron React, Material UI (@mui/material) of React Native gebruikt, is de ondersteuning ingebouwd. Zie Vooraf Geconfigureerde Componentbibliotheken.
Aangepaste mappings: Voor je eigen componenten, maak mappings aan in je configuratie. Zie Linting van Aangepaste Componenten voor een overzicht en vervolgens de stapsgewijze instructies voor VS Code en JetBrains of de REST-endpoint.

Configuratieopties worden gedeeld tussen de IDE-integraties, de Connector en de REST API, en worden gedocumenteerd in Configuratie van Axe DevTools Linter.

4. Beslis Wanneer u Andere Integraties Moet Toevoegen

De integraties in stap 2 dekken de behoeften van de meeste teams. Overweeg de volgende aanvullende integraties als ze aansluiten bij tools die je al gebruikt:

Integratie	Voeg het toe wanneer
SonarQube	Je team al SonarQube gebruikt voor codekwaliteit en je wilt dat toegankelijkheidsproblemen daar verschijnen als externe problemen, naast je andere bevindingen.
Jenkins	Je builds uitvoert in Jenkins en toegankelijkheidscontroles wilt als onderdeel van die builds.
Andere CI/CD-systemen	Je gebruikt Bitbucket, CircleCI, GitLab of Azure DevOps. De Connector biedt de basis voor integratie met deze systemen.

Deze integraties zijn allemaal gebouwd op de Connector, die de lintingresultaten oplevert die elke systeem verbruikt. De algemene regel: grijpt naar een andere integratie wanneer deze toegankelijkheidsbevindingen laat zien in een tool die je team al gebruikt, in plaats van een nieuw tool toe te voegen om het tool zelf.

Alles Samenbrengen

Een typische setup voor een team dat SaaS gebruikt zou kunnen zijn:

De VS Code-extensie (of JetBrains-plugin) voor elke ontwikkelaar, voor feedback tijdens het coderen.
De GitHub-actie bij pull requests, zodat toegankelijkheidsproblemen zichtbaar zijn tijdens code review.
Aangepaste component mappings als het team een ontwerpsysteem gebruikt.
SonarQube integratie alleen als het team daar al codekwaliteit centraliseert.

Een team met strengere eisen voor gegevensverwerking kan SaaS vervangen door de on-premises implementatie en de Connector gebruiken met --local in hun CI/CD-pijplijn, zodat broncode nooit hun netwerk verlaat.

Als u niet zeker weet welke combinatie het beste bij uw omstandigheden past, neem dan contact op met Deque's helpdesk.