Choisir la Bonne Configuration du Linter Axe DevTools

Le linter Axe DevTools peut être utilisé de nombreuses manières, et la bonne combinaison dépend de la façon dont votre équipe écrit, révise et déploie le code. Ce guide passe en revue les principales décisions afin que vous puissiez choisir une configuration adaptée à vos circonstances. La plupart des équipes combinent plusieurs de ces options plutôt que d'en choisir une seule.

Les décisions se répartissent en quatre domaines :

1. Où l'analyse s'exécute (que les fichiers soient analysés localement ou sur un serveur, et quel modèle de déploiement héberge ce serveur)
2. Où le linting se produit dans votre flux de travail (IDE, hook de pré-commit, CI/CD)
3. Si vous devez configurer des bibliothèques de composants
4. Quand ajouter d'autres intégrations telles que SonarQube

1. Choisissez Où l'Analyse S'exécute

Il y a deux choix liés ici : si vos fichiers sont analysés sur votre propre machine ou envoyés à un serveur, et, si un serveur est impliqué, quel type de serveur l'héberge.

Linting Local ou Basé sur Serveur

L'endroit où vos fichiers sont analysés, et si leur contenu quitte votre machine, dépend de l'intégration. Les trois familles d'intégrations se comportent différemment :

• Les intégrations IDE effectuent toujours le linting localement. L'Extension VS Code et le Plugin JetBrains analysent les fichiers sur votre propre machine avec un composant intégré, donc le contenu des fichiers ne quitte jamais votre ordinateur. Ils ne nécessitent pas de clé API ou de clé de licence pour fonctionner.
• Le Connecteur peut fonctionner de l'une ou l'autre manière. Par défaut, le Connecteur envoie les fichiers à un serveur Axe DevTools Linter, mais son --local option les analyse sur votre machine à la place, donc leur contenu ne la quitte jamais. Deque recommande le linting local pour la plupart des cas : il est nettement plus rapide et moins sujet aux problèmes de réseau, surtout lors de l'analyse d'un grand nombre de fichiers. Quelle que soit la manière dont vous effectuez le linting, le Connecteur s'authentifie, comme décrit dans Authentification du Connecteur ci-dessous.
• L'Action GitHub est toujours basée sur un serveur. L'Action GitHub envoie les fichiers modifiés à un serveur Axe DevTools Linter pour analyse. Elle n'a pas de mode de linting local, donc cette option envoie toujours le contenu des fichiers au serveur.

Authentification du Connecteur

Lorsque vous utilisez le Connecteur, vous vous authentifiez avec l'un des deux types d'identifiants, que vous fassiez le linting localement ou sur un serveur :

• Clé API (l'--api-key option) : Vous gérez vous-même les clés API dans le cadre de votre Compte Axe. Le Connecteur contacte un serveur distant pour valider la clé et rendre compte de l'utilisation (les lignes de code analysées). Cela se produit même lorsque vous effectuez le linting localement.
• Clé de licence (l'--license-key option) : Vous demandez une clé de licence à Assistance de Deque. Elle s'authentifie sans activité réseau et ne suit pas l'utilisation, ce qui en fait le bon choix pour les réseaux isolés ou les environnements avec des règles sortantes strictes. Elle est disponible uniquement pour le linting local.

Cela donne au Connecteur trois modes de fonctionnement :

Les intégrations IDE n'ont besoin d'aucune crédential pour l'analyse. L'Action GitHub s'authentifie avec une clé API; son guide d'installation couvre le flux de travail pour les serveurs SaaS et sur site.

Modèle de Déploiement Serveur

Si vous effectuez une analyse sur un serveur, ou si vous vous authentifiez avec une clé API lors d'une analyse locale, vous choisissez également quel type de serveur héberge Axe DevTools Linter. Cela affecte l'effort de configuration, si vos fichiers quittent votre réseau et comment vous vous authentifiez.

Choisissez SaaS pour le démarrage le plus rapide et sans infrastructure à maintenir. Choisissez sur site lorsque la politique exige que le code source reste au sein de votre réseau, ou lorsque vous souhaitez un contrôle total sur le serveur. Choisissez cloud privé lorsque vous souhaitez une instance dédiée gérée par Deque sans gérer le serveur vous-même.

2. Choisissez Où l'Analyse se Déroule dans Votre Flux de Travail

Les retours d'accessibilité sont les plus utiles tôt et souvent. Les intégrations ci-dessous s'appliquent à différents moments du cycle de développement, et elles fonctionnent bien ensemble : repérez les problèmes en tapant, à nouveau avant un commit, et encore une fois dans la pull request.

Une approche courante et structurée est :

1. Extension IDE pour que les développeurs voient les problèmes immédiatement lorsqu'ils écrivent du code.
2. Hook pré-commit ou GitHub Action comme une vérification pour que les problèmes soient détectés avant ou pendant la revue de code.
3. Connecteur dans CI/CD pour appliquer des vérifications à l'ensemble du code et pour alimenter d'autres systèmes.

Vous n'avez pas besoin d'adopter tous les trois niveaux à la fois. Les équipes commencent souvent par l'extension IDE, puis ajoutent une vérification de pull request lorsqu'elles sont prêtes à appliquer des normes à l'ensemble de l'équipe.

3. Décider de configurer ou non les bibliothèques de composants

Par défaut, Axe DevTools Linter vérifie les éléments HTML standard et le balisage des frameworks. Si votre code utilise des composants personnalisés (par exemple, un <custom-image> qui rend un <img>), le linter ne peut pas les vérifier pour l'accessibilité tant que vous ne lui indiquez pas comment chaque composant se mappe à un élément standard.

Vous devriez configurer le linting des composants si :

• Votre base de code repose sur un système de design ou une bibliothèque de composants personnalisés, et
• Vous souhaitez que les problèmes d'accessibilité à l'intérieur de ces composants soient signalés.

Il existe deux voies :

• Bibliothèques de composants préconfigurés : Si vous utilisez Cauldron React, Material UI (@mui/material) ou React Native, le support est intégré. Voir Bibliothèques de Composants Préconfigurés.
• Mappages personnalisés : Pour vos propres composants, créez des mappages dans votre configuration. Voir Linting des Composants Personnalisés pour une vue d'ensemble, puis le guide pour VS Code et JetBrains ou le Endpoint REST.

Les options de configuration sont partagées entre les intégrations IDE, le Connecteur et l'API REST, et sont documentées dans Configuration d'Axe DevTools Linter.

4. Décider Quand Ajouter d'Autres Intégrations

Les intégrations dans étape 2 couvrent les besoins de la plupart des équipes. Envisagez les intégrations supplémentaires suivantes lorsqu'elles correspondent aux outils que vous utilisez déjà :

Ces intégrations sont toutes basées sur le Connecteur, qui produit les résultats de linting que chaque système consomme. La règle générale : optez pour une autre intégration lorsqu'elle permet de faire apparaître les résultats en matière d'accessibilité dans un outil sur lequel votre équipe compte déjà, plutôt que d'ajouter un nouvel outil pour lui-même.

Tout Rassembler

Une configuration typique pour une équipe utilisant des SaaS pourrait être :

• Le Extension VS Code (ou Plugin JetBrains) pour chaque développeur, pour un retour d'information pendant le codage.
• Le GitHub Action sur les demandes de pull, afin que les problèmes d'accessibilité soient visibles lors de la revue de code.
• Mappages de composants personnalisés si l'équipe utilise un système de design.
• intégration SonarQube uniquement si l'équipe centralise déjà la qualité du code là-bas.

Une équipe avec des exigences plus strictes en matière de gestion des données pourrait remplacer le SaaS par le déploiement sur site et utiliser le Connecteur avec --local dans leur pipeline CI/CD afin que le code source ne quitte jamais leur réseau.

Si vous n'êtes pas sûr de la combinaison qui convient à votre situation, contactez le service d'assistance de Deque.