Linting e controlli CI per l'accessibilità

I test vengono eseguiti dopo aver scritto il codice, ma un linter segnala i problemi mentre digita. Prima individua un problema, meno costa correggerlo.

Per i progetti React, il plugin ESLint eslint-plugin-jsx-a11y controlla il JSX alla ricerca dei più comuni errori di accessibilità direttamente nell’editor.

jsx-a11y rileva, ad esempio, un’immagine senza prop alt, un’ancora senza href o un gestore di clic su un elemento non interattivo.

Aggiunga la prop alt e l’avviso scompare. La correzione è minima e Lei l’ha individuata prima ancora che il codice venisse rilasciato.

Un linter legge il codice sorgente, non la pagina visualizzata. Non può misurare il contrasto o l’ordine del focus, quindi integra le scansioni di axe, ma non le sostituisce.

Un gate CI è un controllo che deve essere superato prima di poter fare il merge del codice. Se il test di accessibilità fallisce, la pull request viene semplicemente bloccata.

Senza un gate, un audit fallito è solo un avviso che tutti ignorano. Un gate trasforma l’accessibilità in un requisito, non in un suggerimento cortese.

Un workflow CI installa le dipendenze, quindi esegue i comandi di lint e di test. Un codice di uscita diverso da zero fa fallire automaticamente il job.

Quando la compilazione diventa rossa, l’autore vede nel log la regola e l’elemento esatti che hanno causato il fallimento. Il ciclo di feedback dura minuti, non settimane.

Un gate che si interrompe per motivi sbagliati viene disabilitato. Mantenga i test stabili e circoscritti, così il team può fidarsi del fatto che una compilazione rossa indichi un problema reale.

La configurazione più solida le combina: lint durante la scrittura del codice, axe nei test e un gate CI al momento del merge. Ogni livello rileva ciò che gli altri non riescono a individuare.

Esegua il lint mentre scrive il codice, esegua axe nei test e sottoponga i merge a un gate CI. Insieme, queste protezioni impediscono che le regressioni di accessibilità arrivino al rilascio. 🚦