Das richtige Setup für Axe DevTools Linter wählen

Axe DevTools Linter kann auf viele Arten genutzt werden, und die richtige Kombination hängt davon ab, wie Ihr Team Code schreibt, überprüft und bereitstellt. Dieser Leitfaden führt Sie durch die wichtigsten Entscheidungen, damit Sie ein Setup wählen können, das zu Ihren Gegebenheiten passt. Die meisten Teams kombinieren mehrere dieser Optionen, anstatt sich nur für eine zu entscheiden.

Die Entscheidungen fallen in vier Bereiche:

1. Wo die Analyse abläuft (ob Dateien lokal oder auf einem Server geprüft werden und welches Bereitstellungsmodell diesen Server hostet)
2. Wo das Linting in Ihrem Workflow stattfindet (IDE, Pre-Commit-Hook, CI/CD)
3. Ob Sie Bibliotheken von Komponenten konfigurieren müssen
4. Wann Sie andere Integrationen hinzufügen wie SonarQube

1. Wählen Sie, wo die Analyse abläuft

Hier gibt es zwei verwandte Entscheidungen: ob Ihre Dateien auf Ihrem eigenen Rechner analysiert oder an einen Server gesendet werden und, falls ein Server beteiligt ist, welche Art von Server diesen hostet.

Lokales oder serverbasiertes Linting

Wo Ihre Dateien analysiert werden und ob deren Inhalte Ihren Rechner verlassen, hängt von der Integration ab. Die drei Integrationsfamilien verhalten sich unterschiedlich:

• IDE-Integrationen führen das Linting immer lokal durch. Die VS Code-Erweiterung und das JetBrains-Plugin analysieren Dateien auf Ihrem eigenen Rechner mit einer eingebetteten Komponente, sodass Dateiinhalte Ihren Computer nie verlassen. Sie benötigen keinen API-Schlüssel oder Lizenzschlüssel zum Linting.
• Der Connector kann sowohl lokal als auch serverbasiert linten. Standardmäßig sendet der Connector Dateien zu einem Axe DevTools Linter-Server, aber seine --local Option analysiert sie stattdessen auf Ihrem Rechner, sodass deren Inhalte diesen nie verlassen. Deque empfiehlt lokales Linting für die meisten Fälle: es ist deutlich schneller und weniger anfällig für Netzwerkprobleme, besonders beim Linting großer Dateimengen. Egal, wie Sie linten, der Connector authentifiziert sich, wie in Connector-Authentifizierung unten beschrieben.
• Die GitHub-Aktion ist immer serverbasiert. Die GitHub-Aktion sendet geänderte Dateien zu einem Axe DevTools Linter-Server zur Analyse. Sie hat keinen lokalen Linting-Modus, sodass diese Option Dateiinhalte immer zum Server sendet.

Connector-Authentifizierung

Wenn Sie den Connector nutzen, authentifizieren Sie sich mit einem von zwei Anmeldedaten, unabhängig davon, ob Sie lokal oder gegen einen Server linten:

• API-Schlüssel (die --api-key-Option): Sie verwalten API-Schlüssel selbst im Rahmen Ihres Axe-Konto. Der Connector kontaktiert einen entfernten Server, um den Schlüssel zu validieren und die Nutzung zu melden (die gelininten Codezeilen). Dies geschieht auch, wenn Sie lokal linten.
• Lizenzschlüssel (die --license-key-Option): Sie beantragen einen Lizenzschlüssel bei Deque Help Desk. Er authentifiziert sich ohne Netzwerkaktivität und verfolgt keine Nutzung, was ihn zur richtigen Wahl für netzisolierte Netzwerke oder Umgebungen mit strengen ausgehenden Regeln macht. Er ist nur beim lokalen Linting verfügbar.

Dies gibt dem Connector drei Betriebsmodi:

Die IDE-Integrationen benötigen keine Anmeldedaten zum Überprüfen. Die GitHub-Action authentifiziert sich mit einem API-Schlüssel; ihr Einrichtungsanleitung deckt den Workflow sowohl für SaaS als auch für lokale Server ab.

Server-Bereitstellungsmodell

Wenn Sie gegen einen Server überprüfen oder sich mit einem API-Schlüssel authentifizieren, während Sie lokal überprüfen, wählen Sie auch, welche Art von Server Axe DevTools Linter hostet. Dies beeinflusst den Einrichtungsaufwand, ob Ihre Dateien Ihr Netzwerk verlassen und wie Sie sich authentifizieren.

Wählen Sie SaaS für den schnellsten Start und keine Infrastruktur zur Wartung. Wählen Sie vor Ort, wenn die Richtlinie erfordert, dass der Quellcode innerhalb Ihres Netzwerks bleibt, oder wenn Sie die volle Kontrolle über den Server haben möchten. Wählen Sie private Cloud, wenn Sie eine dedizierte, von Deque verwaltete Instanz ohne eigenen Serverbetrieb wünschen.

2. Wählen Sie, wo die Überprüfung in Ihrem Workflow stattfindet

Barrierefreiheitsfeedback ist am nützlichsten früh und häufig. Die unten aufgeführten Integrationen greifen an unterschiedlichen Punkten im Entwicklungslebenszyklus und arbeiten gut zusammen: Erkennen Sie Probleme, während Sie tippen, erneut vor einem Commit und noch einmal im Pull-Request.

Ein gängiger, gestufter Ansatz ist:

1. IDE-Erweiterung, damit Entwickler Probleme sofort sehen, während sie Code schreiben.
2. Pre-Commit-Hook oder GitHub Action als Gate, um Probleme vor oder während der Code-Überprüfung zu erkennen.
3. Connector in CI/CD, um Prüfungen im gesamten Codebestand durchzusetzen und andere Systeme zu versorgen.

Sie müssen nicht alle drei Ebenen auf einmal einführen. Teams beginnen oft mit der IDE-Erweiterung und fügen dann eine Pull-Request-Prüfung hinzu, sobald sie bereit sind, Standards im gesamten Team durchzusetzen.

3. Entscheiden, ob Sie Komponentenbibliotheken konfigurieren

Standardmäßig prüft Axe DevTools Linter standardmäßige HTML-Elemente und Framework-Markup. Wenn Ihr Code benutzerdefinierte Komponenten verwendet (z. B. eine <custom-image>, die ein <img> rendert), kann der Linter diese nicht auf Barrierefreiheit prüfen, bis Sie ihm mitteilen, wie jede Komponente einem Standard-Element zugeordnet wird.

Sie sollten die Komponenten-Linting konfigurieren, wenn:

• Ihre Codebasis auf ein Designsystem oder eine benutzerdefinierte Komponentenbibliothek angewiesen ist, und
• Sie möchten, dass Barrierefreiheitsprobleme in diesen Komponenten gekennzeichnet werden.

Es gibt zwei Wege:

• Vorkonfigurierte Komponentenbibliotheken: Wenn Sie Cauldron React, Material UI (@mui/material) oder React Native verwenden, ist die Unterstützung integriert. Siehe Vorkonfigurierte Komponentenbibliotheken.
• Benutzerdefinierte Zuordnungen: Erstellen Sie für Ihre eigenen Komponenten Zuordnungen in Ihrer Konfiguration. Siehe Linting benutzerdefinierter Komponenten für einen Überblick, dann das Walkthrough für VS Code und JetBrains oder den REST-Endpunkt.

Konfigurationsoptionen werden über die IDE-Integrationen, den Connector und die REST-API geteilt und sind in Konfiguration von Axe DevTools Linter dokumentiert.

4. Entscheiden, wann Sie weitere Integrationen hinzufügen

Die Integrationen in Schritt 2 decken die Bedürfnisse der meisten Teams ab. Ziehen Sie die folgenden zusätzlichen Integrationen in Betracht, wenn sie zu bereits verwendeten Werkzeugen passen:

Diese Integrationen basieren alle auf dem Connector, der die Lintergebnisse liefert, die jedes System verwendet. Die allgemeine Regel: Greifen Sie zu einer weiteren Integration, wenn sie Barrierefreiheitsfeststellungen in einem Werkzeug sichtbar macht, auf das Ihr Team bereits angewiesen ist, anstatt ein neues Werkzeug eigens hinzuzufügen.

Zusammenführung

Ein typisches Setup für ein Team, das SaaS nutzt, könnte sein:

• Die VS Code-Erweiterung (oder JetBrains-Plugin) für jeden Entwickler, um Feedback während des Codierens zu erhalten.
• Die GitHub Action bei Pull-Requests, damit Barrierefreiheitsprobleme während der Code-Überprüfung sichtbar sind.
• Benutzerdefinierte Komponenten-Zuordnungen, wenn das Team ein Designsystem verwendet.
• SonarQube nur dann integrieren, wenn das Team dort bereits die Codequalität zentralisiert.

Ein Team mit strengeren Anforderungen an die Datenverarbeitung könnte SaaS durch die Vor-Ort-Bereitstellung ersetzen und den Connector mit --local in ihrer CI/CD-Pipeline verwenden, damit der Quellcode ihr Netzwerk nie verlässt.

Wenn Sie unsicher sind, welche Kombination zu Ihren Umständen passt, kontaktieren Sie Deque‘s Helpdesk.