Linting en CI-poorten voor toegankelijkheid

Tests worden uitgevoerd nadat de code is geschreven, maar een linter signaleert problemen terwijl je typt. Hoe eerder je een probleem ontdekt, hoe goedkoper het is om het op te lossen.

Voor React-projecten controleert de eslint-plugin-jsx-a11y-plugin voor ESLint je JSX direct in je editor op veelvoorkomende toegankelijkheidsfouten.

jsx-a11y detecteert bijvoorbeeld een afbeelding zonder alt-prop, een anker zonder href of een klikhandler op een niet-interactief element.

Voeg de alt-prop toe en de waarschuwing verdwijnt. De oplossing is klein en je zag het probleem voordat de code ooit werd uitgeleverd.

Een linter leest de broncode, niet de weergegeven pagina. Hij kan contrast of focusvolgorde niet meten en vormt daarom een aanvulling op axe-scans, geen vervanging.

Een CI-poort is een controle die moet slagen voordat code kan worden samengevoegd. Als je toegankelijkheidstest mislukt, wordt het pull request gewoon geblokkeerd.

Zonder poort is een mislukte audit slechts een waarschuwing die iedereen negeert. Een poort maakt toegankelijkheid tot een vereiste in plaats van een beleefde suggestie.

Een CI-workflow installeert afhankelijkheden en voert daarna je lint- en testopdrachten uit. Een niet-nulwaarde als exitcode laat de taak automatisch mislukken.

Wanneer de build rood wordt, ziet de auteur in het log precies welke regel en welk element zijn mislukt. De feedbacklus duurt minuten, geen weken.

Een poort die om de verkeerde redenen faalt, wordt uitgeschakeld. Houd tests stabiel en beperk ze tot de juiste scope, zodat het team erop vertrouwt dat een rode build op een echt probleem wijst.

De sterkste aanpak combineert alles: linting tijdens het coderen, axe in tests en een CI-poort bij het samenvoegen. Elke laag vangt op wat de andere mist.

Lint tijdens het coderen, voer axe uit in je tests en gebruik een poort voor samenvoegingen in CI. Samen voorkomen deze veiligheidsnetten dat regressies in de toegankelijkheid ooit worden uitgeleverd. 🚦