Scegliere la Giusta Configurazione di Axe DevTools Linter

Axe DevTools Linter può essere utilizzato in diversi modi, e la combinazione giusta dipende da come il tuo team scrive, revisiona e distribuisce il codice. Questa guida illustra le principali decisioni affinché tu possa scegliere una configurazione che si adatti alle tue circostanze. La maggior parte dei team combina diverse di queste opzioni piuttosto che sceglierne solo una.

Le decisioni si dividono in quattro aree:

1. Dove viene eseguita l'analisi (se i file vengono analizzati localmente o su un server e quale modello di distribuzione ospita quel server)
2. Dove avviene l'analisi nel tuo flusso di lavoro (IDE, hook pre-commit, CI/CD)
3. Se hai bisogno di configurare le librerie di componenti
4. Quando aggiungere altre integrazioni come SonarQube

1. Scegli Dove Esegue l'Analisi

Qui ci sono due scelte correlate: se i tuoi file vengono analizzati sul tuo computer o inviati a un server e, se è coinvolto un server, quale tipo di server li ospita.

Linting Locale o Basato su Server

Dove vengono analizzati i tuoi file e se il loro contenuto lascia il tuo computer dipende dall'integrazione. Le tre famiglie di integrazioni si comportano diversamente:

• Le integrazioni IDE analizzano sempre localmente. L'Estensione di VS Code e il Plugin JetBrains analizzano i file sul tuo computer con un componente integrato, quindi il contenuto dei file non lascia mai il tuo computer. Non richiedono una chiave API o una chiave di licenza per l'analisi.
• Il Connettore può eseguire l'analisi in entrambi i modi. Per impostazione predefinita, il Connettore invia i file a un server Axe DevTools Linter, ma la sua opzione --local li analizza sul tuo computer, quindi i loro contenuti non lo lasciano mai. Deque consiglia l'analisi locale nella maggior parte dei casi: è significativamente più veloce e meno soggetta a problemi di rete, specialmente quando si analizzano un gran numero di file. In qualunque modo tu esegua l'analisi, il Connettore si autentica, come descritto in Autenticazione del Connettore qui sotto.
• L'azione GitHub è sempre basata su server. L'Azione GitHub invia i file modificati a un server Axe DevTools Linter per l'analisi. Non ha una modalità di analisi locale, quindi questa opzione invia sempre i contenuti dei file al server.

Autenticazione del Connettore

Quando usi il Connettore, ti autentichi con una delle due credenziali, sia che tu esegua l'analisi localmente sia contro un server:

• Chiave API (l'opzione --api-key): Gestisci le chiavi API autonomamente come parte del tuo Account Axe. Il Connettore contatta un server remoto per convalidare la chiave e segnalare l'uso (le righe di codice analizzate). Questo avviene anche quando esegui l'analisi localmente.
• Chiave di licenza (l'opzione --license-key): Richiedi una chiave di licenza da Help Desk di Deque. Essa si autentica senza attività di rete e non traccia l'uso, il che la rende la scelta giusta per reti isolate o ambienti con rigide regole di uscita. È disponibile solo con analisi locale.

Questo dà al Connettore tre modi di operare:

Le integrazioni IDE non necessitano di credenziali per il lint. La GitHub Action si autentica con una chiave API; la sua guida all'installazione copre il flusso di lavoro sia per i server SaaS che on-premises.

Modello di Distribuzione del Server

Se esegui un lint contro un server o ti autentichi con una chiave API mentre esegui un lint localmente, scegli anche quale tipo di server ospita Axe DevTools Linter. Questo influisce sull'installazione, sul fatto che i tuoi file lascino la tua rete e su come ti autentichi.

Scegli SaaS per il più rapido avvio e nessuna infrastruttura da mantenere. Scegli on-premises quando la politica richiede che il codice sorgente rimanga all'interno della tua rete o quando vuoi avere il pieno controllo del server. Scegli cloud privato quando desideri un'istanza dedicata gestita da Deque senza eseguire il server da solo.

2. Scegli Dove Avviene il Linting nel Tuo Flusso di Lavoro

Il feedback sull'accessibilità è più utile se ricevuto presto e spesso. Le integrazioni indicate di seguito si applicano in diverse fasi del ciclo di vita dello sviluppo e funzionano bene insieme: rileva i problemi mentre digiti, di nuovo prima di un commit e ancora una volta nella pull request.

Un approccio comune e stratificato è:

1. Estensione IDE affinché gli sviluppatori vedano immediatamente i problemi mentre scrivono il codice.
2. Hook pre-commit o Azione GitHub come un filtro, in modo che i problemi vengano individuati prima o durante la revisione del codice.
3. Connettore nei sistemi CI/CD per imporre controlli su tutto il codice e per alimentare altri sistemi.

Non è necessario adottare tutti e tre gli strati contemporaneamente. I team spesso iniziano con l'estensione IDE, poi aggiungono un controllo alle pull request una volta pronti a far rispettare gli standard al team.

3. Decidere se Configurare Librerie di Componenti

Per impostazione predefinita, Axe DevTools Linter controlla gli elementi HTML standard e il markup dei framework. Se il tuo codice utilizza componenti personalizzati (ad esempio, un <custom-image> che rende un <img>), il linter non può controllarli per l'accessibilità finché non gli dici come ogni componente si mappa a un elemento standard.

Dovresti configurare il linting dei componenti se:

• Il tuo codice si basa su un sistema di design o una libreria di componenti personalizzata, e
• Vuoi che i problemi di accessibilità all'interno di questi componenti vengano segnalati.

Ci sono due vie:

• Librerie di componenti preconfigurate: Se utilizzi Cauldron React, Material UI (@mui/material), o React Native, il supporto è integrato. Vedi Librerie di Componenti Preconfigurate.
• Mappature personalizzate: Per i tuoi componenti, crea mappature nella tua configurazione. Vedi Linting dei Componenti Personalizzati per una panoramica, poi il tutorial per VS Code e JetBrains o il Endpoint REST.

Le opzioni di configurazione sono condivise tra le integrazioni IDE, il Connettore e l'API REST, e sono documentate in Configurazione di Axe DevTools Linter.

4. Decidere Quando Aggiungere Altre Integrazioni

Le integrazioni in passo 2 coprono le esigenze della maggior parte dei team. Considera le seguenti integrazioni aggiuntive quando corrispondono agli strumenti che già usi:

Queste integrazioni sono tutte basate sul Connettore, che produce i risultati del linting che ciascun sistema consuma. La regola generale: cerca un'altra integrazione quando permette di far emergere i risultati di accessibilità in uno strumento su cui il tuo team fa già affidamento, piuttosto che aggiungere un nuovo strumento per il suo stesso scopo.

Mettere Tutto Insieme

Una configurazione tipica per un team che utilizza SaaS potrebbe essere:

• Il Estensione VS Code (o il Plugin JetBrains) per ogni sviluppatore, per avere feedback durante la scrittura del codice.
• Il Azione GitHub sulle pull request, in modo che i problemi di accessibilità siano visibili durante la revisione del codice.
• Mappature di componenti personalizzati se il team utilizza un sistema di design.
• SonarQube integrazione solo se il team già centralizza la qualità del codice lì.

Un team con requisiti di gestione dei dati più severi potrebbe sostituire il SaaS con il on-premises e utilizzare il Connector con --local nella loro pipeline CI/CD in modo che il codice sorgente non lasci mai la loro rete.

Se non sei sicuro di quale combinazione si adatti alle tue circostanze, contatta servizio di assistenza di Deque.