Linting og CI-gates for tilgængelighed

Tests kører, efter koden er skrevet, men en linter markerer problemer, mens du skriver. Jo tidligere du opdager et problem, desto billigere er det at løse.

I React-projekter kontrollerer ESLint-plugin'et eslint-plugin-jsx-a11y din JSX for almindelige fejl i tilgængeligheden direkte i din editor.

jsx-a11y opdager blandt andet et billede uden en alt-prop, et anker uden en href eller en klikhåndtering på et ikke-interaktivt element.

Tilføj alt-prop'en, så forsvinder advarslen. Løsningen er lille, og du så den, før koden overhovedet blev udgivet.

En linter læser kildekode, ikke den gengivne side. Den kan ikke måle kontrast eller fokusrækkefølge, så den supplerer axe-scanninger, men erstatter dem ikke.

En CI-gate er en kontrol, der skal bestås, før kode kan flettes. Hvis din tilgængelighedstest fejler, bliver pull requesten ganske enkelt blokeret.

Uden en gate er en fejlslagen kontrol bare en advarsel, som alle ignorerer. En gate gør tilgængelighed til et krav i stedet for et høfligt forslag.

En CI-arbejdsgang installerer afhængigheder og kører derefter dine lint- og testkommandoer. En afslutningskode, der ikke er nul, får automatisk jobbet til at fejle.

Når bygningen bliver rød, kan forfatteren se den præcise fejlslagne regel og det berørte element i loggen. Feedbacksløjfen tager minutter, ikke uger.

En gate, der bryder sammen af de forkerte årsager, bliver deaktiveret. Hold tests stabile og afgrænsede, så teamet stoler på, at en rød bygning betyder et reelt problem.

Den stærkeste opsætning kombinerer dem: lint, mens du koder, axe i tests og en CI-gate ved fletning. Hvert lag opdager det, de andre overser.

Lint, mens du koder, kør axe i dine tests, og brug en gate ved fletninger i CI. Tilsammen forhindrer disse sikkerhedsnet, at tilbagefald i tilgængeligheden nogensinde bliver udgivet. 🚦